the multi-cpu code density contest

[matthey]

Originally Posted by ross

Attached a 54 byte version (with the potential bugs corrected).
Like NorthWay said the real turning would be to avoid using the 1k buffer.
The stream format is really unfriendly.

I converted your LZSS code from Motorola syntax to AT&T and inserted into the source needed by Vince Weaver (attached). I noticed that line 49 of your source is using an op.l while you converted most of this variable to op.w.

   addq.l    #(THRESHOLD+1),d4    ; +1 for the former dbf result

Is there a reason why you did not convert to addq.w (overflow possible)? Should I change this to addq.w? Do you see any other errors?

[ross]

Originally Posted by matthey

I converted your LZSS code from Motorola syntax to AT&T and inserted into the source needed by Vince Weaver (attached). I noticed that line 49 of your source is using an op.l while you converted most of this variable to op.w.

   addq.l    #(THRESHOLD+1),d4    ; +1 for the former dbf result

Is there a reason why you did not convert to addq.w (overflow possible)? Should I change this to addq.w? Do you see any other errors?

Hi matthey, is a simple refusal from the old code, it makes no difference whether .w or .l, no overflow possible.
But to be more consistent I made the decision to make all operations 32bit where possible (anyhow word access at odd locations requires 020+..) and note in braces the minimum required specifier (see attach).

I also corrected a bug that you have reintroduced inserting the original A registers initialization.
If LZSS packed data bound is used in final check you need to cmp.l a4,a3.
See my previous message why i had changed comparison.


Best regards,
ross

[matthey]

Originally Posted by ross

Hi matthey, is a simple refusal from the old code, it makes no difference whether .w or .l, no overflow possible.
But to be more consistent I made the decision to make all operations 32bit where possible (anyhow word access at odd locations requires 020+..) and note in braces the minimum required specifier (see attach).

Right. The code is for 020+ so 32 bit operations are sometimes better performance, especially for 68060. Some programmers may use the code as a reference and it is nice to have it easy to understand and not just optimized for size to the point of being useless. Overall, it is still readable even though the average instruction length is down to ~2.5 bytes/instruction where most compiled code is over 3. This shows the key to improving 68k code density is improving the ISA to make it easier for compilers. If compilers could consistently generate this kind of code density then there would already be an ASIC in the 68k future which would be a game changer for the Amiga. There should be some other interesting ISA comparisons if I can get Vince Weaver in gear. Doing most of the work for him helped last time.

Originally Posted by ross

I also corrected a bug that you have reintroduced inserting the original A registers initialization.
If LZSS packed data bound is used in final check you need to cmp.l a4,a3.
See my previous message why i had changed comparison.

Doh! How did I miss that. Thanks.

[ross]

wait!
With the bound check of the compressed data we can have the same problem of original code.
The only properly check is the unpacked data bound.
But if it was acceptable before..

EDIT: in fact is not the case as original code, the check is at the loop end,
so if the stream is not corrupted last byte/word is ever a byte/word_match copy
(a good collateral effect -> no out of buffer read/write)

Code checked and works


ross

[matthey]

@ross
Good. I already sent an e-mail to Vince today but I linked to this thread in case any late changes were necessary.

Update: Vince e-mailed me but he is busy with school starting.

[ross]

Just noticed that my 54 byte version is not signaled.
http://www.deater.net/weave/vmwprod/asm/ll/
(best is the 56 bytes 8086 version)

68k deserve the throne