Song Liu writes:
> On Thu, May 30, 2019 at 3:34 PM Luke Nelson wrote:
>>
>> On Thu, May 30, 2019 at 1:53 PM Song Liu wrote:
>> >
>> > This is a little messy. How about we introduce some helper function
>> > like:
>> >
>> > /* please find a better name... */
>> > emit_32_or_64(bool is64, const
On Thu, May 30, 2019 at 3:34 PM Luke Nelson wrote:
>
> On Thu, May 30, 2019 at 1:53 PM Song Liu wrote:
> >
> > This is a little messy. How about we introduce some helper function
> > like:
> >
> > /* please find a better name... */
> > emit_32_or_64(bool is64, const u32 insn_32, const u32 inst_64
On Thu, May 30, 2019 at 1:53 PM Song Liu wrote:
>
> This is a little messy. How about we introduce some helper function
> like:
>
> /* please find a better name... */
> emit_32_or_64(bool is64, const u32 insn_32, const u32 inst_64, struct
> rv_jit_context *ctx)
> {
>if (is64)
>
On Thu, May 30, 2019 at 12:09 PM Luke Nelson wrote:
>
> In BPF, 32-bit ALU operations should zero-extend their results into
> the 64-bit registers. The current BPF JIT on RISC-V emits incorrect
> instructions that perform either sign extension only (e.g., addw/subw)
> or no extension on 32-bit ad
In BPF, 32-bit ALU operations should zero-extend their results into
the 64-bit registers. The current BPF JIT on RISC-V emits incorrect
instructions that perform either sign extension only (e.g., addw/subw)
or no extension on 32-bit add, sub, and, or, xor, lsh, rsh, arsh,
and neg. This behavior d
5 matches
Mail list logo
