| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Decrunch direction
So I'm in the middle of updating nucrunch's self extracting file generator to change over to the two-segment no-copy forward decrunch method I pioneered in tinycrunch. The forward decruncher is slightly faster than the reverse, and the two segment method should also make it easer to add support for lowering the minimum start address to 0x0200.
I was just wondering if there was any point in maintaining the reverse decruncher at all - if I drop it, then I can simplify the code somewhat, and maintenance will be saner moving forward. I pretty much only implemented it for SFX purposes, and that requirement is gone now.
Any thoughts?
Definitions:
A forward decrunch reads the input data from the start to the end, and also outputs in the same direction. A reverse decrunch starts from the end of the input data and works backward, and does the same with the output. It's handy for traditional single-segment self extracting files as you don't have to copy the input to high memory before you start decrunching.
Two segment method: two segment SFXes contain two chunks of data - the first decompresses to the area of RAM starting at the end of the loaded data, and the rest is an in-place compressed copy of the rest.
eg
before decrunch: ........daaaaaaaabbbbbb......................
after decrunch: ..d...BBBBBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAA...
where
- a is a compressed copy of the data at A
- b is a compressed copy of the data at B
- d is the decruncher (which copies itself to low memory before executing.) |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Pretty nifty, but how do you handle back references from stream b into data A? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Thanks!
I don't, they're compressed independently - but in practice that only inflates the compressed data by one or two dozen bytes. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
…so, no one actually uses reverse decrunch for anything outside SFXes then? |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: …so, no one actually uses reverse decrunch for anything outside SFXes then?
That would be weird, loading a file where it is supposed to be unchrunched seems much more efficient than allocating space for both the unchrunched file and the chrunched file... |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
That's somewhat orthogonal, Trash. If you're loading to one place and decruching to another (as one might if (eg) preloading the next demo part to high memory, and decrunching over the previous part when switching to it), then the decrunch direction is irrelevant.
Where it does matter, is if you're loading into the destination space. Forward decrunch, and you need to load into the end of the space, reverse, and you load into the start of the space.
I should make some graphs :-/ |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, decrunch direction is only tied to loading direction, and then only when decrunching in-place while loading. That said, reverse loading would be even weirder than reverse decrunch already is. :)
As for thoughts:
Yes, do get rid of reverse decrunch if you can. It wasn't the best idea from the start due to more cycles for hi-byte handling, thus slightly slower than clean forward decrunch. And with your invention of 2-segment decrunching, the copying overhead which backward decrunch is supposed to counter is not relevant any more. Also, fewer test cases are always a good idea.
Only downside would be those few dozen bytes of worse packing ratio, but those only come into play if you're plotting to de-throne Exomizer in terms of packing ratio. (It was always on the slower side, so speed isn't an issue there.) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
(I just realised Trash may have read my "outside" as referring to disjoint memory areas. My apologies if so - I meant "use cases other than") |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ok, looks like I'll be doing a code cleanout.
As for the small impact on compressed data size, looks like I more than gain that back in code size - the forward decrunch routine is about 60 bytes smaller :D |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Be afraid, Exomizer, be VERY afraid. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: That would be weird, loading a file where it is supposed to be unchrunched seems much more efficient than allocating space for both the unchrunched file and the chrunched file...
in a demo usually you dont have free space, when an effect runs and you also load, at the designated decrunch location. |
... 9 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
