| |
oziphantom
Registered: Oct 2014
Posts: 488 |
modify Exomiser compressor to black list some memory locations
Does anybody know a way to modify the exomizer compression algorithm to black list FF0X memory locations to never be read from, i.e don't allow them to be used as part of a sequence?
I guess a post process would also work, if there is a simple way to convert use a sequence to literal bytes.. |
|
... 16 posts hidden. Click here to view all posts....
|
| |
oziphantom
Registered: Oct 2014
Posts: 488 |
Exomizer by default has 16bit offsets, I guess I could force it into 256 offsets, then once I get below fe00 jump to another copy.. or change the get byte routing in ZP to point to different code...
At the moment it works in X128, but fails on hardware and Z64K so I'm trying to work out what the magic combo is... |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Limiting the offsets worsens the pack ratio, i'd try to avoid that.
You can add code to check if the sequence copy read range overlaps $ff00..$ff04 and then select the appropriate routine. Obviously the selection code should be highly optimised.
But if your trick to read RAM in that range only works in VICE and there is no way to achieve that on the real thing, this is all moot, of course. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
just use different code for the whole ffxx page then just one cmp for src hi byte. |
| |
oziphantom
Registered: Oct 2014
Posts: 488 |
well fe and ff as y = ff and pointer is fe01 then lda (pointer),y still hits ff00. And you need to preserve C,V I think, and I can't use the stack... have to double check |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
I think the original idea of modifying the compressor not to reference certain areas would be quite doable. I've considered that for subsizer but haven't really seen an actual use case for it.
If it is only reading you are concerned about, a modification to your favourite compressor's match algorithm should do it. e.g you could have an extra bit (or byte) per data byte that says if this may be included in a match or not. This will result in the whole match database not containing any possible references to that data, always generating output without it in the later steps.
If writing is a problem, you would need to add some way of doing skips in the output. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting oziphantomwell fe and ff as y = ff and pointer is fe01 then lda (pointer),y still hits ff00. And you need to preserve C,V I think, and I can't use the stack... have to double check I think it's most sensible to check the read range in flat memory space to decide on plain copy or $ff0X copy, then apply all those banking/stack relocation shenanigans to actually copy bytes around. :)
The decision should be made per sequence copy, not per source byte. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1403 |
Quoting KrillThe decision should be made per sequence copy, not per source byte.
Sure, but it's still going to be slower than just blacklisting those particular source bytes. That's an extra check for every token - particularly harsh given that exo also uses copies for recently used single bytes. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting ChristopherJamQuoting KrillThe decision should be made per sequence copy, not per source byte. Sure, but it's still going to be slower than just blacklisting those particular source bytes. That's an extra check for every token - particularly harsh given that exo also uses copies for recently used single bytes. Yes, disallowing certain memory ranges on the compressor side is the preferred option, IF it is available. :)
Quoting ChristopherJamThat's an extra check for every token - particularly harsh given that exo also uses copies for recently used single bytes. An extra check for every sequence-copy token. However, it should be highly optimisable. The check only needs to be performed once the problematic range has actually been written to, and as its high-byte is $ff, the back-reference check in flat memory space should allow for early exit. There may be more opportunities for optimisation. |
| |
oziphantom
Registered: Oct 2014
Posts: 488 |
not write, read
so if when you are writing to $4000 and it wants to copy a 128 bytes sequence and that sequence starts at fE88, then the first 8 reads(as it reads from the top down) need to be the special read under FF0X code. So in order to know if it needs normal, or special, you need to do
(Start + X + Len).hi > ff where start and len are 16bits 'then do special' is probably the best case. It might be faster overall to just do Start.hi + Len.hi > fd and take the hit rather than take the hit of 16bits for the rest.
ChristopherJam is right Exomizer loves to do a sequence of 1 byte.
I have written Magnus Lind, and he sees that it might be useful for other systems as well, and if its not too much work he is happy to make "black list intervals" a feature of exomizer. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting oziphantomnot write, read A sequence cannot be read from before it has been written initially (and writing is not a problem, if i have understood you right). The write pointer is strictly ascending or descending depending on depack direction, and thus the range check is superfluous before the problematic range has been written to. This is why i wrote "The check only needs to be performed once the problematic range has actually been written to". |
| Previous - 1 | 2 | 3 - Next |
