Index
> Main > I'll tell you why FASM is better!Goto page 1, 2 Next |
| Author |
|
|
Reverend 26 Sep 2006, 19:58
Hmm... Generally it's nice you like fasm, but:
1 - you don't know much in asm, but you managed to have 334,123b ~= 0,31MB of source code which is compilable under nasm and fasm; weird... 2 - as far as I know every assembler outputs 'db' bytes directly to file; is there any other way?  |
|||
26 Sep 2006, 19:58 |
|
|
2 26 Sep 2006, 20:26
Quote:
That huge source file was made with a C program I wrote. It is kinda like a hex dump,but instead of using hex,it uses db to reproduce the original qbasic.exe . It's hardly useful,but it is the sort of fun thing you can do with assemblers. Yes,most assemblers do db the same,but FASM is way faster! |
|||
|
26 Sep 2006, 20:26 |
|
|
arafel 26 Sep 2006, 21:18
Reverend wrote:
Yes, but some assemblers handle this in a worst way possible. For example it will take ages for MASM to assemble something like "db 1000000 dup(?)". Apparently NASM also suffers from this.. |
|||
|
26 Sep 2006, 21:18 |
|
|
rugxulo 27 Sep 2006, 04:27
From the NASM manual:
Quote:
Make sure you aren't using -O999v or some other ridiculous option (which can take forever, e.g. newg162.asm from ZSNES). P.S. FASM can be slow in some circumstances too (e.g. too many Windows macros), read this. |
|||
|
27 Sep 2006, 04:27 |
|
|
Madis731 27 Sep 2006, 10:33
btw, 2, if you love using FASM to just generate ...erm... files?..then you should see some other topics regarding outputting TGA and BMP files, also using FASM to produce some imput data to other programs. The macro facilities are the BEST for this.
We have IDs here in Estonia, that are 11 numbers long. Mine for example is 38410190245 and from that you can read persons sex, date of birth and I needed to generate some random million of them  I used FASM and btw it also automatically checked the validity of this.
(I must have it somewhere  ) |
|||
|
27 Sep 2006, 10:33 |
|
|
f0dder 27 Sep 2006, 10:39
Madis731: isn't it a bad idea to disclose your social security number? At least in many countries (including .dk), once you have the SSN and a few other pieces of information, you can do all kinds of identity theft.
|
|||
|
27 Sep 2006, 10:39 |
|
|
Kain 27 Sep 2006, 19:47
Sure, FASM is great... but not because it's fast (TASM is probably faster)! FASM has much more going for it than just speed.
|
|||
|
27 Sep 2006, 19:47 |
|
|
vid 27 Sep 2006, 20:24
i believe TASM isn't faster.
by the way, it's speed is more important than most people realize. Slowness of compilers introduced things like separate compiling of modules to object files, and then linking into one executable. FASM allows you to have entire big project in one file, without waiting too long for recompilation. Sometimes this is advantage, sometimes not. In assembly, it's mostly IS an advantage. |
|||
|
27 Sep 2006, 20:24 |
|
|
arafel 27 Sep 2006, 21:06
vid wrote: FASM allows you to have entire big project in one file, without waiting too long for recompilation. Sometimes this is advantage, sometimes not. In assembly, it's mostly IS an advantage. I wonder if there any benefit from this. Small source code will assemble fast anyway. But how about those with more than 5000 lines of code? It's a pain in the arse to have something like that in a single file  |
|||
|
27 Sep 2006, 21:06 |
|
|
f0dder 27 Sep 2006, 22:21
One big "monofile.asm" requires specialized tools if you want to navigate easily. It also locks out having multiple people develop concurrently on the same project, at least without pretty tedious merging.
With separate files, you can use standard tools, and things like subversion (or cvs, if you haven't moved on yet) makes multi-developer work so much easier. Even if you're only a single person on a project, version control is wonderful. Okay, so far I've ruled "monofile.asm" out, but what about include vs. separate modules? Even if you can assemble a bazillion lines per second, thus ignoring the "only re-assemble what's needed" quality, only having separate files can give you separate namespaces. Functions with local labels and local data does help, but it's nice being able to use just "wndproc" or "dlgproc" instead of longer names. If you're into code re-use, it's nice knowing that a .asm module builds, can (possibly) be re-used, and that include ordering won't break anything, and you the exact dependencies by looking at the module, not the modules that might include it... I don't see the .inc method giving any advantages over separate .asm modules, except that you can "fasm mainfile.asm" instead of dealing with makefiles or the like. |
|||
|
27 Sep 2006, 22:21 |
|
|
vid 27 Sep 2006, 22:36
arafael: sometime it's pain not to have it in one file... it depends.
and nobody says you need to have it in one file, look at fasmlib for example. f0dder: about separate namespaces you are right of course. but if you look at usual code, everything is enclosed in rather small function anyway, and inside this function you should use local names anyway. so we are talking only about names of functions and data of course. and look at programs which use "tricky" naming, often it makes them harder to read. and yes, advantage is not dealing with makefiles, and not having problems with recompiling etc. etc. I believe you already tried to install some huge C source-only program on BSD  |
|||
|
27 Sep 2006, 22:36 |
|
|
Kain 27 Sep 2006, 22:50
vid wrote: i believe TASM isn't faster. by the way, it's speed is more important than most people realize. Slowness of compilers introduced things like separate compiling of modules to object files, and then linking into one executable. FASM allows you to have entire big project in one file, without waiting too long for recompilation. Sometimes this is advantage, sometimes not. In assembly, it's mostly IS an advantage.[/quote] Not really important. The differences in speed between FASM/MASM/GoASM/TASM is irrelevant enough to warrant looking deeper into the feature set and convenience of the assembler. I don't fancy monosource in either case and the reasons pro/con have already been brought up here. IMO, monosource is only good for single-developer small programs which negates the speed advantage. _________________ :sevag.k |
|||
|
27 Sep 2006, 22:50 |
|
|
f0dder 27 Sep 2006, 22:54
Quote:
"tricky" naming is what you might end up needing if you only use one source module - "editor_wndproc", "find_wndproc", "edit_subclass_wndproc", etc whatever. Nicer to separate to modules and just use "wndproc", imho. But at least it's not grossly bad as long as you split into functions and use local names. Not doing that sucks . Also, look at (afaik) how TASM has problems and you thus end up having to prefix your struct member names...
Quote:
Not a big advantage, though. Regular makefiles suck, but a more capable environments like SCons is pretty comfortable to work with. Quote:
Haven't had problems with it on BSD, compile-from-source has mostly been a problem on linux boxes without decent package management, in trying to track down dependencies... and then the occasional glitch, like fixing proftpd's SSL code (though I don't take credit for that, was a friend who fixed it). |
|||
|
27 Sep 2006, 22:54 |
|
|
Tomasz Grysztar 28 Sep 2006, 07:06
Just my two cents: the advantage of compiling directly into the target instead of modules allows to make better optimizations of code size - something that fasm likes.
As for the makefiles, I actually considered them a great thing in a old days when I was using TASM. I don't really get why you think they "suck". |
|||
|
28 Sep 2006, 07:06 |
|
|
f0dder 28 Sep 2006, 07:08
Quote:
The syntax when you need non-trivial things, and for C/C++ all the bother to set up dependencies. SCons handles dependencies automagically and has nicer syntax |
|||
|
28 Sep 2006, 07:08 |
|
|
vid 28 Sep 2006, 07:13
because they make compilation depend on more thing. i had to compile few bigger programs on BSD, and NONE of them just compiled by itself, modyfications to makefiles were needed.
I like makefiles for some things (build asm file, build C file, link them), but they are often (?mis?)used to make "too much", not just as batch of compilation process. |
|||
|
28 Sep 2006, 07:13 |
|
|
Tomasz Grysztar 28 Sep 2006, 07:19
Oh, so I just used them for the simple things, perhaps the "trivial" ones.
|
|||
|
28 Sep 2006, 07:19 |
|
|
f0dder 28 Sep 2006, 07:31
vid wrote: because they make compilation depend on more thing. i had to compile few bigger programs on BSD, and NONE of them just compiled by itself, modyfications to makefiles were needed. "ports" is your friend - if it's not there, though, things do get uglier. I prefer binary packages, most of the time there isn't much use in recompiling yourself. Except with a few of the very overbloated applications where it's nice to turn down the featuritis a bit - but that wouldn't be necessary, either, if the applications could dynamically support available features/libraries, instead of needing them hardcoded at compile time. vid wrote:
The whole idea of makefiles is to automate. Preferably, the entire build process, including setting up zip/tgz/installers, running tests, etc. Tomasz Grysztar wrote: Oh, so I just used them for the simple things, perhaps the "trivial" ones. Have a look at what a typical 10+ file linux program Makefile, with all the autoconf crap, looks like... not pretty. IMHO the whole idea of autoconf is wrong anyway, people shouldn't support broken platforms. And "make dep" isn't necessary with better tools. _________________  - carpe noctem |
|||
|
28 Sep 2006, 07:31 |
|
|
tom tobias 28 Sep 2006, 13:04
Quote:
It was good in 1970. Today, I prefer smaller, simpler, fewer manipulations, more efficiency with greater transparency. Makefiles was born out of necessity, how to manage the gargantuan size and quantity of source code? A new OS is imperative, written in asm, not C, using FEWER Intel instructions, to facilitate debugging. Linux, C, makefiles, etc, they were all satisfactory solutions for that dynamic era, three decades ago, but now the time has arrived, to move forward to a new era.... |
|||
|
28 Sep 2006, 13:04 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|