OSDev.org

I'm just back from school and i found a way of compressing ASM files. Imagine 2K of assembly raw code becomes compiled into 126 bytes of machine code. Now, you can "compress" this by getting the machine code of that, and in a case where it's just a pattern of "FA, FE, 3F", you could do this and compress the raw code:
Now, let's see. That raw assembly is 287 bytes long. So basically;
we just compressed the .asm file (not the .bin) into 287 bytes.
The only issue is that this defines a word, which is 8 bytes. But we're trying to define a 126 byte word. NASM fortunately shows this as not a assembler instruction so there is no limit.
Disclaimer: This only compresses the .asm file. The binary result is not affected.

But - why?

You could as well assemble it and disassemble it again if you want to see the source.

Amazing. I'm speechless.

kzinti wrote:Amazing. I'm speechless.

The .bin result is exactly the same size as the non compressed one. So this would be a great way to compress your source ASM files, but the BIN files will be the exact same.

And your file ends up consuming just as much disk space as the 2k original. That was clever.

iansjack wrote:And your file ends up consuming just as much disk space as the 2k original. That was clever.

i never knew 2,000 = 278

I think what you don't know is how files are stored on disks.

iansjack wrote:I think what you don't know is how files are stored on disks.

read the DISCLAIMER

I think that you are missing the point that I am making, which is applicable to many aspects of programming.

There is no point spending resources "optimizing" a program if that optimization has no effect.

Shouting doesn't affect the validity of that observation.

Hi,


Even if disk space occupied by a file is rounded up by one block (usually 4096 bytes on UNIX filesystems), still a compressed file transmits faster over a network.

But this does not change the fact that I did not understand how was the assembly file actually compressed. What optimisations did you apply so the compressed file is smaller?


Regards,
glauxosdever

glauxosdever wrote:Hi,


Even if disk space occupied by a file is rounded up by one block (usually 4096 bytes on UNIX filesystems), still a compressed file transmits faster over a network.

But this does not change the fact that I did not understand how was the assembly file actually compressed. What optimisations did you apply so the compressed file is smaller?


Regards,
glauxosdever

The compressed .ASM file is smaller by around 8+ times, but the .BIN file and machine code is exactly the same size.
About how it was compressed; you do not have to create the 2,000 bytes. The code provided is 287 bytes and produces the same result, making it a great space saver. Also promotes security and demotes 7 year olds that try to copy the code but then ask their local doctor why their kiddie code isn't working. Basically, pretty useful for source code if you want security to your code.

NunoLava1998 wrote:

glauxosdever wrote:Hi,


Even if disk space occupied by a file is rounded up by one block (usually 4096 bytes on UNIX filesystems), still a compressed file transmits faster over a network.

But this does not change the fact that I did not understand how was the assembly file actually compressed. What optimisations did you apply so the compressed file is smaller?


Regards,
glauxosdever

The compressed .ASM file is smaller by around 8+ times, but the .BIN file and machine code is exactly the same size.
About how it was compressed; you do not have to create the 2,000 bytes. The code provided is 287 bytes and produces the same result, making it a great space saver. Also promotes security and demotes 7 year olds that try to copy the code but then ask their local doctor why their kiddie code isn't working. Basically, pretty useful for source code if you want security to your code.

Ah, the good old "ingenuous coder thinks obfuscating code like hell will be more 'secure'". It really won't. It's just very inconvenient for the person that's reading it. It doesn't promote security. The instructions are still there and it's easy to decode them.

heat wrote:

NunoLava1998 wrote:

glauxosdever wrote:Hi,


Even if disk space occupied by a file is rounded up by one block (usually 4096 bytes on UNIX filesystems), still a compressed file transmits faster over a network.

But this does not change the fact that I did not understand how was the assembly file actually compressed. What optimisations did you apply so the compressed file is smaller?


Regards,
glauxosdever

The compressed .ASM file is smaller by around 8+ times, but the .BIN file and machine code is exactly the same size.
About how it was compressed; you do not have to create the 2,000 bytes. The code provided is 287 bytes and produces the same result, making it a great space saver. Also promotes security and demotes 7 year olds that try to copy the code but then ask their local doctor why their kiddie code isn't working. Basically, pretty useful for source code if you want security to your code.

Ah, the good old "ingenuous coder thinks obfuscating code like hell will be more 'secure'". It really won't. It's just very inconvenient for the person that's reading it. It doesn't promote security. The instructions are still there and it's easy to decode them.

true, but not everyone has a decoder and i haven't seen anyone that knows machine code

Hi,


So it is simply machine code encoded in a hexadecimal number? Running NASM to assemble a hexadecimal constant makes no sense, better simply tell the user to download the binary version (and release only the binary version if you think releasing the source code goes against security). Although someone can still get the binary and disassemble the instructions in it.


Regards,
glauxosdever

max wrote:But - why?

You could as well assemble it and disassemble it again if you want to see the source.

If you assemble/disassemble, I think you lose some of your data, like label names and string values.

On the other hand, if you "compress" your code as suggested, you definitely lose your labels and your string values..

I guess as long as you never need to modify your code (i.e. you always get it right the first time), then this would be a perfectly viable option... right?