On 09/21/2017 06:58 PM, Edward Cree wrote:
On 21/09/17 17:40, Y Song wrote:
On Thu, Sep 21, 2017 at 9:24 AM, Edward Cree <ec...@solarflare.com> wrote:
On 21/09/17 16:52, Alexei Starovoitov wrote:
imo
(u16) r4 endian be
isn't intuitive.
Can we come up with some better syntax?
Like
bswap16be r4
bswap32le r4
Hmm, I don't like these, since bswapbe is a swap on *le* and a nop on be.
Agree, a bit too much 'swap' semantics in the name that could be
confusing perhaps, at least the be/le could be missed easily.
or
to_be16 r4
to_le32 r4
And the problem here is that it's not just to_be, it's also from_be.
More intuitive, but agree on the from_be/le. Maybe we should
just drop the "to_" prefix altogether, and leave the rest as is since
it's not surrounded by braces, it's also not a cast but rather an op.
Could you explain what is "from_be" here? Do not quite understand.
Taking the example of a little-endian processor:
cpu_to_be16() is a byte-swap, converting a u16 (cpu-endian) to a __be16.
be16_to_cpu(), to convert a __be16 to a u16, is *also* a byte-swap.
Meanwhile, cpu_to_le16() and le16_to_cpu() are both no-ops.
More generally, the conversions between cpu-endian and fixed-endian for
any given size are self-inverses. eBPF takes advantage of this by only
having a single opcode for both the "to" and "from" direction. So to
specify an endianness conversion, you need only the size and the fixed
endianness (le or be), not the to/from direction. Conversely, when
disassembling one of these instructions, you don't know whether it's a
cpu_to_be16() or a be16_to_cpu(), because they both look the same at an
instruction level (they only differ in what types the programmer thought
of the register as holding before and after).
Yeah, exactly to the point. :)
