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: