| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Clarifies that this is the next remainder we're extracting
|
|
The u64() macro is now for _casting_ as uint64_t, whereas the u64c()
macro is for declaring a uint64_t constant (literally appending ULL).
|
|
|
|
TODO: Obvious test fails - fix it
|
|
|
|
Implement sole_encode_realign() which takes care of re-aligning the way
the input is read.
An arbitrary byte buffer might not be 32-byte aligned, which causes the
stream to be misaligned. Given a fresh buffer, we must first ensure that
we re-align with 32 bytes.
|
|
Identifying whether we received odd or even blocks didn't query the
correct size.
|
|
|
|
Essentially modelled on zlib's API, which requires some setup from the
user, but also offers a lot of flexibility.
- Add inp and outp pointers to input and output respectively
- Require set sizes for data available in input and output
|
|
Now cmd-sole and sole_file agree on 64-bit output.
|
|
|
|
|
|
|
|
Haskell and C implementations now read the input in the same way. So
they should produce the same output.
|
|
Their byte output should be the same (just allows us to inspect that the
data is processed identically)
|
|
TODO REALLY IMPORTANT! Check sole_encode_file() reads input in the "correct"
order. One way to see this is to finish the poc/cmd-sole tool and have it output
a 64-bit block view of a file (and compare outputs)
|
|
|
|
|
|
Checking for i3 == 0 and setting rem both have macros that do this. Use them.
|
|
|
|
|
|
I'm pretty confident this works, and it should be pretty useful later on. More
testing is required though.
|
|
|
|
For multiplying with a 128-bit number. Needs testing.
Provide declaration for blk256_div_blk128()
|
|
Get rid of previous implementation and use only the multiplication version
(it should in the general case be faster).
Document the multiplication procedure.
|
|
The intermediate dividend in sole_pass2_rev_regroup() was extracted wrong, which
caused the correct numbers to appear, but in the wrong places.
|
|
Given a three-digit number x=(x3,x2,x1) that we want to divide by a two-digit
number say y=(y2,y1) we can always take out x3 times y when x3 > 0 and add that
to the relevant part of the quotient. Using this observation can save lots of
time by doing a multiplication and a subtraction instead of x3 subtractions.
Furthermore, the blk256_sub() function turned out to be broken and untested, so
implement rudimentary tests and fix the errors.
|
|
Rename strm->outfd to strm->out, and correct a few things in sole_file.c
Expand on the sole_encode_file() function and actually begin to process files.
As predicted the division performs poorly...
|
|
This test perfectly demonstrates how a better strategy for performing the
division is required.
|
|
|
|
The results are computed directly in the output parameters x and y
|
|
Only one instance of computing y
|
|
|
|
Tests for sole_pass1_rev_compose(), with fixes.
|
|
This adds sole_pass1_rev_decompose() which reverses the decomposition step in
pass 1.
Also add sole_pass1_rev_compose() which reverses the composition step in pass 1.
|
|
This step should, for a given double-block, reverse to enumerated computation
and produce the quotient and remainder (intermediate results from pass1).
The division implemented is long division for which I predict very poor results
as the divisior B+3i forces us to use three 64-bit blocks during the division
phase instead of two. This most likely leads to poor performance, since the
third block in B+3i is always 1 (the smallest possible), and potentially needs
to be subtracted 2^64 times from the third block of the dividend.
|
|
|
|
Add even-block handling as introduced in branch 'debug'. This is just a copy (no
merge)
Introduce sole_stream_free() in the API, allowing users to explicitly freeing a
sole_stream. This could be useful in error situations where the stream needs to
be abandoned before completion.
|
|
|
|
|
|
|
|
Implement simple long division to reduce running time.
There are still remaining errors, so the [5, 7, (2^128)-1] example still doesn't
seem to give the right result (but it is close)
|
|
Also detect infinite loops
|
|
And swap x and &w in blk256_add() as x may equal the output operator, but we
know &w is different than rop.
|
|
Closing a stream by calling sole_encode_end() takes care of finalising the
stream with proper EOF indication.
Currently the representation of 128-bit blocks makes handling EOF a little
clunky (for example the compose() function cannot be used directly).
Also, regroup() didn't properly handle the case where the output destination was
the same as the larger input.
Signed-off-by: Thomas Jespersen <laumann.thomas@gmail.com>
|
|
|
|
|
