Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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:
BITS 16
times 0-($-$$) db 0
dw 0xFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFAFE3FFA
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.
Last edited by NunoLava1998 on Tue Oct 18, 2016 1:25 pm, edited 1 time in total.
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
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.
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
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?
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.
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
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.
If some of you people keep insisting on having backwards compatibitity with the stone age, we'll have stone tools forever.
My Hobby OS: https://github.com/heatd/Onyx
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
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
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.
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?
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
