flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 Next |
Author |
|
HaHaAnonymous 16 Jan 2014, 13:29
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 18:29; edited 1 time in total |
|||
![]() |
|
sid123 17 Jan 2014, 06:55
Quote: I'm not a real programmer then (expected). The only manual I have read was the Intel manual, everything else I learned the "hard-way" (trial and error). I didn't say that reading manuals is useless, I said that most people can't learn from just reading manuals, they need some 3rd party aid like examples, sources etc. Don't you think so? That's how every one learns. Manuals are for complex tasks, I think people starting with assembly (x86) should first start from reading tutorials and assembly examples rather than reading the Intel Manual, since tutorials "assume" that you are a beginner, after you've had enough experience with assembly then you should consider Intel Manuals as your learning resource. I feel there is nothing called a "real" programmer, it just that some people are hobbyist coders, they aren't serious as opposed to people who are professional and write everything on their own. _________________ "Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X XD |
|||
![]() |
|
HaHaAnonymous 17 Jan 2014, 15:07
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 18:28; edited 1 time in total |
|||
![]() |
|
sid123 30 Jan 2014, 06:55
Quote: I attempted my first MASM 'hello world' program... until at the end of the code where I got the end main vs endp conflict poisoning both sides of my brain. I never truly recovered since then. One thing: MASM will be dead in a few years, It's high time that those unsophisticated programmers stop using MASM and start with a free assembler like NASM/FASM _________________ "Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X XD |
|||
![]() |
|
sinsi 30 Jan 2014, 07:59
sid123 wrote: MASM will be dead in a few years Microsoft still use it for low-level stuff (and drivers) sid123 wrote: It's high time that those unsophisticated programmers stop using MASM and start with a free assembler like NASM/FASM I can't remember much of a choice in 1986, there was MASM and...TASM/A86 maybe? |
|||
![]() |
|
HaHaAnonymous 30 Jan 2014, 11:14
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 18:23; edited 1 time in total |
|||
![]() |
|
DOS386 01 Feb 2014, 08:14
upsurt wrote: Thank you, AsmGuru62! Does NASM need a linker? No ASM needs a linker. Just FASM can brew MZ and PE while NASM can't. But you can always brew MZ or PE manually. Or you can use a linker with FASM (but not the OMF format). |
|||
![]() |
|
edfed 01 Feb 2014, 14:46
what is a linker???
is that this strange thing that generate binary around binary, and generate LNKXXXX ERRORS if it doesn't find a .lib referenced in a configuration file via a path variable... if it does it, it is just a symbol offset assembler, than, it is just an aspect of assembler. if it does that, the source code just need to know where to pick symbols, not to know where the .lib is, cause the .lib is just a crappy file type, not source code, not property file, not anything like readable file, and is just intended to bloat your job when you want to compile a simple application in a multiMegaBytes binary file full of 0's |
|||
![]() |
|
PeExecutable 26 Jun 2015, 18:11
<popping a very old thread here>
I've used tasm, masm, fasm, nasm and a little bit of yasm and used each of them for a couple of months, a few of them for many years. Here is what I think of flat assembler so far: 1. Nice and clean, small, extremely fast (according to my tests it outperforms other assemblers by over ten thousand times, which is insane in and of itself) 2. Extremely powerful macro system, but here starts my pessimism. Because the macro system of fasm ships at the very bones, whenever a programmer creates a new macro and shares it on the internet, people won't understand the macro immediately, because there are no standard macro instructions used in a macro designed from the bone, which makes it extremely inefficient to share macros with other people. Here is where I strongly bless NASM, because if you share a macro designed in NASM, chances are very high he'll understand that macro immediately because it's not designed from the bones and up, it has a little bit of skin on it too, initially. 3. Extreme simplifity with the combined assembler and integrated linker, this is something I highly appreciated when I first used FASM, but after a while, I really (REALLY) missed the command line options you find in other assemblers and when I moved away from FASM to a more complex command line assembler, I was happy again, I mean REALLY happy. Simplicity is not always a good thing, believe me and I hope FASM will reconsider this in the future, even a tiny more option on the command line is better than none at all. 4. I was disappointed when I tried to use an interface in fasm from inside a function, I could not allocate an interface inside the local definitions and had to use a global one for the interface. I have probably done something wrong? 5. Naming conventions in fasm tends to favor shorter names than longer more descriptive names. I think FASM can learn from HTML here. Why isn't HTML designed with shorter names to save bandwidth? Because you don't actually save bandwidth and secondly because shorter names is a bad thing to do. Very long names are bad, if you can find such beautiful naming conventions like NASM uses, things like __float32__(0.1) which is perfect in length and has a very stylish name, with the cool underscores. When you are compiling a piece of source code, you don't save bandwidth by having a name at 10 bytes versus 50 bytes. The operating system have to read 4096 bytes anyway from the disk and most names don't make up even 8% of the size of the source file. When you ship something with a name that is short, the user have to open the manual and spend 5 minutes to figure out what it is doing. If you give it 2, 3 or 5 more characters, 5 minutes are saved for the programmer. It's not wise to count on that the programmer will learn to remember the short names, because if the assembler consists of too many of them, and the programmer rarely needs to use them frequently, he will not learn to remember them and so he will constantly be peeking in the manual. However, if the assembler has very few names, few macro instructions, shorter names can be used because it's easy to remember a few of them. The people who designed the __floatxx__ naming convention with the two underscores on both sides, those people were absolutely ingenious, they understand that the visual sensory of the programmer can much more easily remember the word floatxx if its between horizontal lines, pictural memory is more effective than the literal memory if combined. Learn from them. In my understanding, the goal of fasm is to narrow down everything until you can fit everything at the pin of a needle, so that it's easier to take control of your life, whether it be in bed or behind the screen. Try not to walk that path too much, we masters know what we're talking about. ![]() You're NOT going to lose a partner if you add some command line options to fasm. My personal wish is that we see more of FASM in the future, not so much FASCISM. This is a wisdom you WILL adapt to later in life, you might as well do it early on, I guarantee that you'll change your mind later. ![]() |
|||
![]() |
|
fasmnewbie 26 Jun 2015, 22:31
"we masters know what we're talking about"
Masters don't rely on C to make their assembly code to work. |
|||
![]() |
|
PeExecutable 27 Jun 2015, 03:59
It's necessary to have an assembler written in a HLL language to avoid the death of the assembler when the author passes away. It's called 'being smart' and its an investment.
And you don't rely in C, you're thinking about the source code of the assembler, but the assembler executable is already assembly code, and the assembler phase is not cruical. |
|||
![]() |
|
fasmnewbie 27 Jun 2015, 05:02
Master, judging from your response, I have this funny feeling that you don't know what you are talking about. But hey, I use NASM too you know. In fact there are lots of NASM users in here too due to syntactic compatibility between these two. So I hope you don't simply get offended by threads like this. Come on...
|
|||
![]() |
|
PeExecutable 27 Jun 2015, 05:28
You were the first person to mention offended
|
|||
![]() |
|
fasmnewbie 27 Jun 2015, 05:48
PeExecutable wrote: You were the first person to mention offended Friends? |
|||
![]() |
|
nasm 03 Feb 2025, 15:09
fasm is without doubt the fastest assembler that I've tried and when you use it, it just works great and there doesn't seem to be anything that stops you when using it. No wonder, it was developed by a highly intelligent man, so when highly intelligent men do things, you get good things in return.
nasm was also originally made by a highly intelligent man, but like has been said, it was written in c and you are going to get at least half the performance when preprocessing and assembling. If you want speed, you use fasm. If you want a fully working assembler, you use fasm. If you want a little less complicated macro system at the expense of speed, then you'll use nasm. Masm, there is too much controversy with it, disclaimers, tools being released with their visual studio, pain to extract, etc. I've used masm and it was fun, but it's a big thing. Big fat elephant. also, if you don't want to use a separate linker, then you'll use fasm, because it's on the inside. You can also make resources from the source code, which is a very good thing to have. The only downside is the macro system of fasm, which is highly complex, and the reason it is highly complex is because it is so compact to begin with. The less keywords you have available, the more compact it will be. Just like math, its a highly compact language and you have to have a clear head when using fasm. In Nasm, you have a keyword for every occation, and there is no need to become obsessed with either one of them, there is another one if you don't like the first two. The problem with nasm is that (Especially if you use windows) is that 1: It's very slow 2: You need a separate linker 3: There are no macro packages, except nasmx, which is kind of ugly 3b: You have to create everything from scratch 4: The structure system is nasty and not very good 5: The developers on the forum have a 15 year reaction time, if you post a bug, it will be solved 15 years later. But if you post a bug to fasm forum, it will be solved in 3 days. But if you care about being a technical assembly coder, if you use nasm (that comes without macro packages) and you code assembly at the rawest ugliest low level you can imagine, you'll become more proficient with assembly overall in the long run. If you use fasm, you're just one level above that, and you'll not become as good with assembly. In nasm, YOU reserve the shadow space, YOU write the procedure call macros, YOU write the stack frame and release the stack frame function PROLOGUE and EPILOGUE. YOU write the local handling in each procedure. In the beginning this is ugly, but after a while you become way more proficient with assembly by using pure raw nasm. It gets super ugly. Nasm is just that, a shoe. There is no shoebox, no paper around it, no nothing, no receit. Just a shoe and its in your mailbox, will you use it? Also, you can assembly to a raw flat binary, which is very useful. It has tons of options. |
|||
![]() |
|
AsmGuru62 03 Feb 2025, 18:45
I agree, FASM is awesome!
PROC/ENDP in FASM rule in a big way! I disagree about being "less proficient" using FASM. Overall, your analysis is very good! |
|||
![]() |
|
sylware 04 Feb 2025, 11:43
When I code x86_64 assembly, I have a thin layer using a C preprocessor in order to write simple generic assemly code which will work-ish with FASM(2)/NASM/GAS.
|
|||
![]() |
|
nasm 05 Feb 2025, 11:42
more and better precise error replies when compiling, shortens learning curve, time savior. Spending too much time learning is a thing of the past, fasm must find a way to overcome the time problem.
The formula is easy, if you spend 1 second less, you are going in the right direction. If you take away options and freedom from the user, you are moving in the wrong direction. Better error replies when compiling <- More compile options <- assembly coders like to have control, don't automate too much Documentation is too dry, it must be softened down to a more humane language. 1. <- better error replies when compiling 2. <- docs too dry (And somewhat too long too) 3. <- More options more freedom, less automation Must find a way to give more options at the same time that they gain more options and control, it becomes more efficient in the same run, which is hard to achieve As it is right now, it is becoming more efficient at the cost of less options, which is an easy thing to do, but wrong also. Assembly is a ferrari, you must stop building on top of it trying to make it look like a humvee. I could cut the docs in half, think about that. 50% reduction in words, yet easier to read. Less dry docs. Instead of building a humvee, try to build a ferrari that comes with a hammer, every guy who buys that ferrari can use the hammer to build a humvee. Stop selling humvees. Macro system is too compact, unreadable, more keywords. Human eyes were not meant to read zip files. They CAN but should spend their calories elsewhere, so they can relax their feet. |
|||
![]() |
|
revolution 05 Feb 2025, 13:07
nasm wrote: I could cut the docs in half, think about that. 50% reduction in words, yet easier to read. Less dry docs.. |
|||
![]() |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.