flat assembler
Message board for the users of flat assembler.
Index
> Main > How small could fasm be? Goto page 1, 2 Next |
Author |
|
l_inc 05 Jan 2015, 01:02
bubach
Without answering the actual question, I'd like to point out that the macro capabilities can actually help you reduce the size of the generated code while preserving its readability and modifiability. E.g. you could write a couple of macros that automatically replace push 0 with push ebx in case the instruction is in a block of code where ebx is guaranteed to be zero. _________________ Faith is a superposition of knowledge and fallacy |
|||
05 Jan 2015, 01:02 |
|
revolution 05 Jan 2015, 02:06
Why the fascination about the size of the executable? Are you running out of disk space?
|
|||
05 Jan 2015, 02:06 |
|
bubach 05 Jan 2015, 07:40
No not really. Just for fun, and also the reason for me to use assembly is to get away from HLL constructs. I know lots of people have great use of the macros functionalities, I'm just not one of them. I'm also curious what a parser as capable as the fasm macro-engine uses up in space. I'd love to be able to run the macro parsing first if needed with one executable, and then do the assembly with a separate executable as well. That too, for fun.
|
|||
05 Jan 2015, 07:40 |
|
neville 05 Jan 2015, 10:24
I don't use fasm macros much either, partly because imho they reduce the "purity" of assembly language as a "second-generation" language. If I wanted to use a 3GL I would do so, but I prefer a bare-metal 2GL to a 2.5GL
Also, I made a fork of fasm version 1.48 many years ago for my memory-os FAMOS, and fasm macros were difficult to accommodate due to their particular memory requirements. In some DOS trials I commented out all macro processing in the preprocessor, but it didn't reduce the resulting code size much (despite taking out a few hundred lines of source code). The original DOS executable for version 1.48 is 51561 bytes, and my macro-free DOS trial version was about 49800 bytes. So only about a 3.5% reduction. Removing unused variables etc could optimise it down a bit more, but probably not significantly. _________________ FAMOS - the first memory operating system |
|||
05 Jan 2015, 10:24 |
|
MIHIP 05 Jan 2015, 11:18
Try my clone of flat assembler named "fast assembler".
http://board.flatassembler.net/topic.php?p=174117#174117 |
|||
05 Jan 2015, 11:18 |
|
shutdownall 05 Jan 2015, 11:50
revolution wrote: Why the fascination about the size of the executable? Are you running out of disk space? I hate too much overloaded programs in general as well (as experienced retro and microcontroller programmer with code size much less 64 kB). Waste of disk space and memory is widely present and I wonder if people today can really program or just click this and that library together which has thousand other functions or purposes. But I wouldn't say that FASM is overloaded. It is really good as it is and I like the one exe file application really much. If you don't mind the INI file but this is pretty much better than using (and leaving) dozens of registry entries in windows for example. |
|||
05 Jan 2015, 11:50 |
|
Tomasz Grysztar 05 Jan 2015, 12:07
bubach wrote: So I'm gonna assume most of this extra is due to different preprocessing add-ons, like macros? Correct me if I am wrong. Supporting AVX/AVX2 and XOP instruction sets added about 20k to the size of fasm binary, so this is probably the most substantial part of the fasm's growth. The new instruction sets are quite complex, and the instructions usually have very long names - it all adds up. fasm's preprocessor measures about 20k, while the combined size of parser, assembler and formatter modules is nearly 60k, counting only the code and not the data tables that contain the names of instructions, registers, etc. Current length of instruction table is about 15k and the contribution of AVX/AVX2/XOP instruction sets was nearly 8k, more than a half of current size (!). |
|||
05 Jan 2015, 12:07 |
|
bubach 05 Jan 2015, 15:35
Wow, ok that would explain it. Thanks for the detailed breakdown on the different part sizes. I would probably never, ever touch those advanced instructions sets either. So I'm still kind of tempted to try and rip out what I consider to be unnecessary for a mini-Fasm distro. Rather then to just use an older version which may have bugs.
We'll see... In any case - 100kb is still pretty amazing Tomasz, no doubt |
|||
05 Jan 2015, 15:35 |
|
shutdownall 05 Jan 2015, 21:50
Well - you can strip down your own version with less functionality.
The key is FASM.INC which you will find depending on which version you use. I think the call to preprocessor call preprocessor can be skipped and at the end of FASM.INC you can find the includes and disable the include of preproce.inc and avx.inc. And about the half of x86.inc you may delete all mmx instructions or instructions you never use. Don't know if there are any initializations skipped when disabling preproce.inc but you will find out easily. Diving into FASM is not that difficult, procedures and code sequences are well named to detect their purpose and this way you can get a very personal edition with maybe 50k or so. |
|||
05 Jan 2015, 21:50 |
|
DOS386 06 Jan 2015, 07:08
> Why the fascination about the size of the executable?
Because bloat matters. And it's better to care about it since the beginning. If you don't, you end up with a 3 MiO assembler ( hello "GAS" ) or a 30 GiO distro (Win 8, Linux, ...). PS: http://wiki.freepascal.org/Size_Matters |
|||
06 Jan 2015, 07:08 |
|
neville 06 Jan 2015, 10:33
shutdownall wrote: I think the call to preprocessor _________________ FAMOS - the first memory operating system |
|||
06 Jan 2015, 10:33 |
|
l_inc 06 Jan 2015, 14:29
neville
Quote: The entire preprocessor can not be "skipped" unless the parser is modified to create the preprocessed format Preprocessing is basically symbolic substitution. There's no such thing as "preprocessed format". _________________ Faith is a superposition of knowledge and fallacy |
|||
06 Jan 2015, 14:29 |
|
system error 06 Jan 2015, 15:31
ment4l is your friend.
|
|||
06 Jan 2015, 15:31 |
|
Tomasz Grysztar 06 Jan 2015, 15:55
l_inc wrote: neville |
|||
06 Jan 2015, 15:55 |
|
l_inc 06 Jan 2015, 17:29
Tomasz Grysztar
Oh. Thanks for the correction. I had a notion of fasm using kind of a byte-code format after the parsing stage, but didn't think preprocessing could do that either. neville Sorry for being too confident about that. Happens rarely to me. _________________ Faith is a superposition of knowledge and fallacy |
|||
06 Jan 2015, 17:29 |
|
neville 07 Jan 2015, 09:28
I_inc No worries We don't really need to have "notions"; we only have to read the source that Tomasz has given us
_________________ FAMOS - the first memory operating system |
|||
07 Jan 2015, 09:28 |
|
revolution 07 Jan 2015, 10:06
neville wrote: We don't really need to have "notions"; we only have to read the source that Tomasz has given us |
|||
07 Jan 2015, 10:06 |
|
l_inc 07 Jan 2015, 12:33
neville
Quote: We don't really need to have "notions"; we only have to read the source You do need notions for some things, if your time is finite. _________________ Faith is a superposition of knowledge and fallacy |
|||
07 Jan 2015, 12:33 |
|
DOS386 12 Jan 2015, 11:28
bubach wrote: Hi, I'm basically wondering how small you could get fasm if you stripped most features not directly associated with instruction->binary conversion. In other words removing all macro-support and so on. Remove the junk formats (MZ, PE, COFFEE, ELF, ...), remove the XXX64 junk, then remove the junk SSE/AVX instructions (you get a P1 MMX assembler), then remove MMX and the 486/P1 junk + FPU junk (you get an 386 assembler), then (WARNING : at this point FASM stops being able to compile itself) remove the 32-bit and 286 junk, getting a cool 8086 assembler, finally, remove junk 8086 instructions (POPE CS, AAA, AAM, INTO, BOUND, ...) keeping only the most common ones. PS: a smallest disassembler challenge: http://board.flatassembler.net/topic.php?t=10874 |
|||
12 Jan 2015, 11:28 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.