-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRAFT: Add bit_order support #373
Conversation
Benchmark for 01edc23Click to view benchmark
|
617763c
to
4067135
Compare
Benchmark for 02fe189Click to view benchmark
|
Benchmark for e6e42a6Click to view benchmark
|
Benchmark for 27866faClick to view benchmark
|
Benchmark for 04c62aaClick to view benchmark
|
f629510
to
2e3b114
Compare
Benchmark for 7fe1cb1Click to view benchmark
|
Here is also test for deku bit_order.rs. When added it fails with message:
Seems every other value is handled correctly, but the value_c has some weird problem. I have validated multiple times that the 6073 is correct value, so the test is valid.
|
Found the bug in reader.rs:
should be below
Working code:
|
You can find the fix and related test from here: https://github.com/tpisto/deku/tree/impl-reader-bit-order2 |
New problem - even with the fix I did for the previous error: With data: 0xE8, 0x25, 0xF4
field_b should be 8000244, but instead deku parses it as 1243764 |
Thanks for testing this and finding bugs! |
Just so I understand the problem. The following is the current behavior: #[derive(Debug, DekuRead, DekuWrite, PartialEq)]
#[deku(endian = "little", bit_order = "lsb")]
pub struct Test {
#[deku(bits = 1)]
field_a: bool,
#[deku(bits = 23)]
field_b: u32,
}
// |||| ||| <-
let data = vec![0b1111_1110, 0b1111_0000, 0b1111_0000];
let bit_order_little = Test::try_from(data.as_ref()).unwrap();
assert_eq_hex!(
bit_order_little,
Test {
field_a: false,
// ||| |||| <-
field_b: 0b111_1000_0111_1000_0111_1111,
}
); Where do those bits that I outlined fall in the correct assertion? |
Add from_reader and use Read internally to improve the codegen of deku, the performance of derived parsers. Internally, this is implemented using the new src/reader.rs interface in deku parses. This has a waterfall effect on DekuReader implementations and the deku-derive/deku_read Derived impl. Previous usage with from_bytes and other API's are unchanged. There is somewhat of a performance hit for bit-only parses, but I find the major improvments in the bytes-wise parsing to be great enough to warrent this change. The following are some sample benchmarks: > critcmp before after group after before ----- ----- ------ deku_read_bits 1.24 845.8±14.29ns ? ?/sec 1.00 679.5±11.83ns ? ?/sec deku_read_byte 1.00 17.8±0.25ns ? ?/sec 2.12 37.8±3.35ns ? ?/sec deku_read_enum 1.00 15.3±0.15ns ? ?/sec 2.04 31.2±0.81ns ? ?/sec deku_read_vec 1.00 676.8±7.04ns ? ?/sec 2.16 1459.5±40.22ns ? ?/sec deku_write_bits 1.00 125.3±3.10ns ? ?/sec 1.04 130.2±11.12ns ? ?/sec deku_write_byte 1.00 161.6±4.86ns ? ?/sec 1.02 165.0±5.91ns ? ?/sec deku_write_enum 1.00 105.6±1.06ns ? ?/sec 1.03 109.0±7.20ns ? ?/sec deku_write_vec 1.00 4.6±0.04µs ? ?/sec 1.06 4.9±0.07µs ? ?/sec The above change removes DekuRead, and replaces it with DekuReader. This contains the from_reader_with_ctx. DekuContainerRead contains from_reader. The crate no_std_io was picked to supply a Read impl for the no_std feature. These are "re-export"ed. Add "`Read` enabled" docs to lib.rs Add tests/test_tuple.rs tests Update CHANGELOG.md to reflect changes and help migration to this usage Use llvm-cov in ci for the generation of more accurate coverage reports Update benchmarks to test more complex parser speeds Disable Miri CI Update ensure_no_std to work with new Read usage. Remove wee-alloc in favour of an updated crate for the allocator. Add inline to small functions
c300f40
to
91bb702
Compare
@tpisto could you elaborate? Thanks |
2e3b114
to
67027f0
Compare
Benchmark for d401fcdClick to view benchmark
|
91bb702
to
979afff
Compare
67027f0
to
bcaab04
Compare
Benchmark for 5500508Click to view benchmark
|
979afff
to
c821840
Compare
6f17200
to
c2a3dc8
Compare
8a3596b
to
79ebce6
Compare
7297dc4
to
26c00d3
Compare
I think the bit_order setting is not working in conjunction with padding bits yet. Consider this testcase: #[derive(DekuRead, DekuWrite, Debug)]
#[deku(bit_order = "lsb")]
struct DekuTest {
pad: u8,
#[deku(bits=6, pad_bits_after = "10")]
flag: u16,
sent: u8,
}
#[test]
fn dekutest() -> Result<(), DekuError> {
let data = vec![0x13, 0x75, 0x0, 0xFF];
let (_, dt) = DekuTest::from_bytes((&data, 0))?;
let to_bytes = dt.to_bytes()?;
println!("{:?}", data);
println!("{:?}", to_bytes);
Ok(())
} Output is
Although as far as I can tell the value in dt.flag is correct, so reading works, but writing back doesn't. |
16aef36
to
3bb6e31
Compare
Is anyone working on this? |
Not currently. I needs a fun rebase on top of current master. |
Closing in favor of rebased #468 |
this is fixed in #468 |
Something like this:
See tests/bit_order.rs in this MR for more examples.