View attachment lzo_decompress_safe.txthi guys.,
can sombody help me to understand the logic behind the lzo_decompress_safe program.
i need thal logic in my hardware project, where im receiving a packet which has compressed or non-compressed data, if it is compressed i need to decompress it and send it to some other module else send the packet as it is.

i tried to understand the logic of lzo_decompression code but i cant get it.
without understanding the logic it is difficult to convert it into hardware language. and i dont know java too.
find the program in the attachments.,
if you know help me...,
thanks.,

 

I agree that taking apart a piece of code has its challenges. I have 2 questions for you:

1. Was there any documentation of the algorithm that came with the code?
2. Why do you think it is Java?

I suggest you start with the following page

http://www.oberhumer.com/opensource/lzo/

Scroll down and click on the documentation link

 

1) i accept that it was my mistake that i didnt search for any documentation.,
and thanks for the documentation link.,

2) i got the code from the following link (last part from the code)

http://java-compress.googlecode.com...ccc0ae120/src/org/jvcompress/lzo/MiniLZO.java

there the author says the code is .java based thats why i think it is java.

 

If the code is Java, do you have the ability to run it under control of a debugger so you can see what is going on? That might be easier than trying to crunch a paper copy. If instead it was compiled C/C++ it might require a greater investment in tools. I would also come up with some test data blocks so you can see what it does with them.

 

@papabravo.,
i've read the documentation but i didnt get anything about the algorithm bcz it seems he discussed about the versions of algorithms and he compares them.,
so, i thought of converting the code into h/w language (verilog or vhdl) as it is .,
and then comparing the results, if it results same i can use.
now tell me whether this thing really works on h/w (any compatible fpga board) or not..?

 

I wish I could give you the definitive answer that you are looking for, but I can't. Generally speaking it should be possible to mimic the behavior of a serial algorithm expressed in a procedural language like Java. The advantage you have in hardware is to exploit the possibility of doing things in parallel. This is extremely difficult in a procedural language, like Java. For notable attempts in this area I remember the folks at University of Illinois (Urbana) who tried to develop a FORTRAN dialect for the Illiac-IV