Re: LZ: Compression program


[Prev][Next][Index][Thread]

Re: LZ: Compression program



On Sun, 8 Sep 1996, Ben Shakal wrote:


> >That's a good idea, there's the ZShell header the first two bytes, and 
> >then the desription of the program next, so it might be 15 or so.  But 
> >maybe the first byte after the description could tell the unzipper and 
> >zipper how many bytes to skip, like this:
> >
> >$02, $FF,$FF <this is the high score, and then comes the acrtual code
> >^
> >skip two bytes
> >This could take some refining, but it's a start
> >Alan B.
> >NEW E-mail-  bailala@mw.sisna.com
> 
> maybe, the first byte after the description should be $C9 because that is
> the opcode for RET.  That way, if someone ran it without the decompressor,
> then it would simple return to ZShell.  Then could come the number of bytes
> to skip, then the actual bytes, then the rest of the program.  Then there
> would still be two problems:
>    1) How does the decompressed program access the those saved bytes?


Find the address of the compressed program string and write into
the decompressed portion.  This should be fairly simple.


>    2) How does a programmer actually specify the number of bytes to save and
> their starting value when writing the program?


The programmer wouldn't have to worry about it.  All programs would
be compressed beginning at a certain offset and the bytes before that
would be uncompressed.  That offset would be the same for all programs.


> For problem #1, the decompressor could place those bytes immediately before
> the start of the decompressed program.  That way, the program could access
> them by taking PROGRAM_ADDR and subracting the neccessary offset instead of
> adding it.  (There is still the question of how to allocate the memory to
> put the decompressed program in, unless this whole project waits for ZS4.5. :-)
I may be mistaken but I think PROGRAM_ADDR gives you the address
of the executing program, which would be the decompressed program.
The address of the compressed string is what would be needed.


> For problem #2, one possible way of doing this could be to have the
> compressor (running on the computer) actually ask the user how many bytes to
> save and what their initial value should be.  A better way would be to put
> it in the ASM source, but I do not know how the compressor would extract it
> correctly.


That could be done by imbedding the number in, say byte 3 of the
executable.  But that would only work for new programs so it wouldn't
really be practical.  The sensible way is to have a fixed number of
uncompressed bytes for all programs.  It would waste a few bytes per
program, possibly, but would save a lot more bytes in the reduced code
for the decompressor.  It also avoids the temptation some programmers
might have to leave large uncompressed areas for whatever reason.


Barry


References: