On 09/24/2017 07:50 AM, Alexei Starovoitov wrote:
On Fri, Sep 22, 2017 at 09:49:10PM -0700, Y Song wrote:
On Fri, Sep 22, 2017 at 9:23 AM, Edward Cree <ec...@solarflare.com> wrote:
On 22/09/17 16:16, Alexei Starovoitov wrote:
looks like we're converging on
"be16/be32/be64/le16/le32/le64 #register" for BPF_END.
I guess it can live with that. I would prefer more C like syntax
to match the rest, but llvm parsing point is a strong one.
Yep, agreed. I'll post a v2 once we've settled BPF_NEG.
For BPG_NEG I prefer to do it in C syntax like interpreter does:
ALU_NEG:
DST = (u32) -DST;
ALU64_NEG:
DST = -DST;
Yonghong, does it mean that asmparser will equally suffer?
Correction to my earlier statements: verifier will currently disassemble
neg as:
(87) r0 neg 0
(84) (u32) r0 neg (u32) 0
because it pretends 'neg' is a compound-assignment operator like +=.
The analogy with be16 and friends would be to use
neg64 r0
neg32 r0
whereas the analogy with everything else would be
r0 = -r0
r0 = (u32) -r0
as Alexei says.
I'm happy to go with Alexei's version if it doesn't cause problems for llvm.
I got some time to do some prototyping in llvm and it looks like that
I am able to
resolve the issue and we are able to use more C-like syntax. That is:
for bswap:
r1 = (be16) (u16) r1
or
r1 = (be16) r1
or
r1 = be16 r1
for neg:
r0 = -r0
(for 32bit support, llvm may output "w0 = -w0" in the future. But
since it is not
enabled yet, you can continue to output "r0 = (u32) -r0".)
Not sure which syntax is best for bswap. The "r1 = (be16) (u16) r1" is most
explicit in its intention.
Attaching my llvm patch as well and cc'ing Jiong and Jakub so they can see my
implementation and the relative discussion here. (In this patch, I did
not implement
bswap for little endian yet.) Maybe they can provide additional comments.
This is awesome. In such case I'd like to swing back to the C syntax for
bpf_end :)
Any of these
r1 = (be16) (u16) r1
or
r1 = (be16) r1
or
r1 = be16 r1
are better than just
be16 r1
I like 1st the most, since it's explicit in terms of what happens with upper
bits,
but 2nd is also ok. 3rd is not quite C-like.
But above cast to be16 also doesn't seem quite C-like in terms
of what we're actually doing... 3rd option would be my personal
preference even if it doesn't look C-like, but otoh we also have
'call' etc which is neither.
