32 bits width of branch_count field in format 0, subformat 0

[zhangdujiao]

For optional Branch prediction mode, if the conditions for sending a branch are met, and pbc ≥31, the TE will send format 0, subformat 0 to report branch_count rather than branch_map by Format 1. But the width of branch_count field is fixed at 32 bits, which is actually too large for the compress purpose, and branch_count field can even hardly overflow (pbc needs to be greater than 2^32+31). Can the width be reduced to a reasonable value? What is the recommended value? The width in table is fixed to 32 bits. If we reduce it, whether can the software decode it?

[IainCRobertson]

What's your concern here? Packets with branch_fmt = 10 should be very rare, so the impact on encoding efficiency should be negligible. There is currently no support for the branch_count width being less than 32. If you reduce it, you could modify your decoder accordingly, but this would be non-compliant and wouldn't interoperate with other standard decoders.

Iain

From: zhangdujiao @.> Sent: 24 June 2024 07:37 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] 32 bits width of branch_count field in format 0, subformat 0 (Issue #120)

For optional Branch prediction mode, if the conditions for sending a branch are met, and pbc ≥31, the TE will send format 0, subformat 0 to report branch_count rather than branch_map by Format 1. But the width of branch_count field is fixed at 32 bits, which is actually too large for the compress purpose, and branch_count field can even hardly overflow (pbc needs to be greater than 2^32+31). Can the width be reduced to a reasonable value? What is the recommended value? The width in table is fixed to 32 bits. If we reduce it, whether can the software decode it?

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/120, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXRA3KVLK3ICH2BIV3ZI647LAVCNFSM6AAAAABJZFSWY6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DSMZVGQ4TMOI. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[zhangdujiao]

What's your concern here?

What's your concern here? Packets with branch_fmt = 10 should be very rare, so the impact on encoding efficiency should be negligible. There is currently no support for the branch_count width being less than 32. If you reduce it, you could modify your decoder accordingly, but this would be non-compliant and wouldn't interoperate with other standard decoders. Iain From: zhangdujiao @.> Sent: 24 June 2024 07:37 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.> Subject: [riscv-non-isa/riscv-trace-spec] 32 bits width of branch_count field in format 0, subformat 0 (Issue #120) For optional Branch prediction mode, if the conditions for sending a branch are met, and pbc ≥31, the TE will send format 0, subformat 0 to report branch_count rather than branch_map by Format 1. But the width of branch_count field is fixed at 32 bits, which is actually too large for the compress purpose, and branch_count field can even hardly overflow (pbc needs to be greater than 2^32+31). Can the width be reduced to a reasonable value? What is the recommended value? The width in table is fixed to 32 bits. If we reduce it, whether can the software decode it? - Reply to this email directly, view it on GitHub<#120>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXRA3KVLK3ICH2BIV3ZI647LAVCNFSM6AAAAABJZFSWY6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DSMZVGQ4TMOI. You are receiving this because you are subscribed to this thread.Message ID: @*.**@*.***>>

My concern is 32bits width branch_count couldn't bring any compression optimization compared to without branch prediction mode, which should send Format 1 originally.

Format 1: 38 bits Format 0 sub 0: 36/37 bits branch prediction mode brings little bandwidth optimization.

[IainCRobertson]

I disagree. Most of the time, the upper bits of branch_count and all the bits above it will be zero and will compress away, resulting in a very short packet.

Iain

From: zhangdujiao @.> Sent: 24 June 2024 10:33 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] 32 bits width of branch_count field in format 0, subformat 0 (Issue #120)

What's your concern here?

What's your concern here? Packets with branch_fmt = 10 should be very rare, so the impact on encoding efficiency should be negligible. There is currently no support for the branch_count width being less than 32. If you reduce it, you could modify your decoder accordingly, but this would be non-compliant and wouldn't interoperate with other standard decoders. Iain From: zhangdujiao @.> Sent: 24 June 2024 07:37 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.> Subject: [riscv-non-isa/riscv-trace-spec] 32 bits width of branch_count field in format 0, subformat 0 (Issue #120https://github.com/riscv-non-isa/riscv-trace-spec/issues/120) For optional Branch prediction mode, if the conditions for sending a branch are met, and pbc ≥31, the TE will send format 0, subformat 0 to report branch_count rather than branch_map by Format 1. But the width of branch_count field is fixed at 32 bits, which is actually too large for the compress purpose, and branch_count field can even hardly overflow (pbc needs to be greater than 2^32+31). Can the width be reduced to a reasonable value? What is the recommended value? The width in table is fixed to 32 bits. If we reduce it, whether can the software decode it? - Reply to this email directly, view it on GitHub<#120https://github.com/riscv-non-isa/riscv-trace-spec/issues/120>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXRA3KVLK3ICH2BIV3ZI647LAVCNFSM6AAAAABJZFSWY6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DSMZVGQ4TMOI. You are receiving this because you are subscribed to this thread.Message ID: @.@.***>>

My concern is 32bits width branch_count couldn't bring any compression optimization compared to without branch prediction mode, which should send Format 1 originally.

Format 1: 38 bits Format 0 sub 0: 36/37 bits branch prediction mode brings little bandwidth optimization.

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/120#issuecomment-2186044089, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSU6RKS2RK65KYWMRCDZI7RVZAVCNFSM6AAAAABJZFSWY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWGA2DIMBYHE. You are receiving this because you commented.Message ID: @.**@.>>

[zhangdujiao]

I disagree. Most of the time, the upper bits of branch_count and all the bits above it will be zero and will compress away, resulting in a very short packet. Iain From: zhangdujiao @.> Sent: 24 June 2024 10:33 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] 32 bits width of branch_count field in format 0, subformat 0 (Issue #120) What's your concern here? What's your concern here? Packets with branch_fmt = 10 should be very rare, so the impact on encoding efficiency should be negligible. There is currently no support for the branch_count width being less than 32. If you reduce it, you could modify your decoder accordingly, but this would be non-compliant and wouldn't interoperate with other standard decoders. Iain From: zhangdujiao @.> Sent: 24 June 2024 07:37 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.> Subject: [riscv-non-isa/riscv-trace-spec] 32 bits width of branch_count field in format 0, subformat 0 (Issue #120<#120>) For optional Branch prediction mode, if the conditions for sending a branch are met, and pbc ≥31, the TE will send format 0, subformat 0 to report branch_count rather than branch_map by Format 1. But the width of branch_count field is fixed at 32 bits, which is actually too large for the compress purpose, and branch_count field can even hardly overflow (pbc needs to be greater than 2^32+31). Can the width be reduced to a reasonable value? What is the recommended value? The width in table is fixed to 32 bits. If we reduce it, whether can the software decode it? - Reply to this email directly, view it on GitHub<#120<#120>>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXRA3KVLK3ICH2BIV3ZI647LAVCNFSM6AAAAABJZFSWY6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DSMZVGQ4TMOI. You are receiving this because you are subscribed to this thread.Message ID: @.@.>> My concern is 32bits width branch_count couldn't bring any compression optimization compared to without branch prediction mode, which should send Format 1 originally. Format 1: 38 bits Format 0 sub 0: 36/37 bits branch prediction mode brings little bandwidth optimization. - Reply to this email directly, view it on GitHub<#120 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSU6RKS2RK65KYWMRCDZI7RVZAVCNFSM6AAAAABJZFSWY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWGA2DIMBYHE. You are receiving this because you commented.Message ID: @*.**@*.***>>

oh I forget the compression method, thanks.