flat assembler
Message board for the users of flat assembler.

Index > Main > How small could fasm be?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
bubach



Joined: 17 Sep 2004
Posts: 341
Location: Trollhättan, Sweden
bubach 04 Jan 2015, 23:44
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.

Reason I ask is I noticed since I last downloaded fasm w32 version (probably v1.60 or so) it has grown from ~70kb to ~100kb and I'm not sure even adding x64 instruction set back in the day accounted for as much as 30kb.

So I'm gonna assume most of this extra is due to different preprocessing add-ons, like macros? Correct me if I am wrong.

I basically never use it, and have a borderline perverted fascination with as small executables as possible - so that is why I'm wondering.

Have anybody tried slimming down the already impressive 100kb further by for example removing macro support? And if so, what was the resulting filesize for just the basic assembler?

_________________
BOS homepage: http://bos.asmhackers.net/
Post 04 Jan 2015, 23:44
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 05 Jan 2015, 01:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20459
Location: In your JS exploiting you and your system
revolution 05 Jan 2015, 02:06
Why the fascination about the size of the executable? Are you running out of disk space?
Post 05 Jan 2015, 02:06
View user's profile Send private message Visit poster's website Reply with quote
bubach



Joined: 17 Sep 2004
Posts: 341
Location: Trollhättan, Sweden
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. Smile
Post 05 Jan 2015, 07:40
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
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 Smile
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
Post 05 Jan 2015, 10:24
View user's profile Send private message Visit poster's website Reply with quote
MIHIP



Joined: 14 Feb 2013
Posts: 130
MIHIP 05 Jan 2015, 11:18
Try my clone of flat assembler named "fast assembler".
http://board.flatassembler.net/topic.php?p=174117#174117
Post 05 Jan 2015, 11:18
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
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. Wink
Post 05 Jan 2015, 11:50
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland
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 (!).
Post 05 Jan 2015, 12:07
View user's profile Send private message Visit poster's website Reply with quote
bubach



Joined: 17 Sep 2004
Posts: 341
Location: Trollhättan, Sweden
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
Post 05 Jan 2015, 15:35
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
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.
Wink
Post 05 Jan 2015, 21:50
View user's profile Send private message Send e-mail Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1905
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" Smile ) or a 30 GiO distro (Win 8, Linux, ...).

PS: http://wiki.freepascal.org/Size_Matters
Post 06 Jan 2015, 07:08
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville 06 Jan 2015, 10:33
shutdownall wrote:
I think the call to preprocessor
call preprocessor
can be skipped
The entire preprocessor can not be "skipped" unless the parser is modified to create the preprocessed format required by the assembler. This would not be a trivial task.

_________________
FAMOS - the first memory operating system
Post 06 Jan 2015, 10:33
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 06 Jan 2015, 14:29
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 670
system error 06 Jan 2015, 15:31
ment4l is your friend.
Post 06 Jan 2015, 15:31
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland
Tomasz Grysztar 06 Jan 2015, 15:55
l_inc wrote:
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".
neville is right, fasm uses a specific format for the preprocessed source. It was originally described in a never-finished guide to fasm's internals and later I copied this information into the documentation of .fas format, as fasm stores such preprocessed source there. The "prepsrc" tool converts this format back into plain text.
Post 06 Jan 2015, 15:55
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 06 Jan 2015, 17:29
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville 07 Jan 2015, 09:28
I_inc No worries Smile We don't really need to have "notions"; we only have to read the source that Tomasz has given us Wink

_________________
FAMOS - the first memory operating system
Post 07 Jan 2015, 09:28
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20459
Location: In your JS exploiting you and your system
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 Wink
When all else fails, read the source. Hmm ... now where have I seen that before?
Post 07 Jan 2015, 10:06
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
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
Post 07 Jan 2015, 12:33
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1905
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. Smile

PS: a smallest disassembler challenge: http://board.flatassembler.net/topic.php?t=10874
Post 12 Jan 2015, 11:28
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.