flat assembler
Message board for the users of flat assembler.

Index > Heap > Why FASM? And NOT C/C++

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



Joined: 17 Jan 2012
Posts: 369
uart777
WHY I USE FASM? AND NOT C/C++/VC/VisualStudio

* Macros? FASM: Yes, powerful macro features, #1 reason. C/C++: Weak, limited preprocessor.

* Optimization? FASM: Depends on the programmer. C/C++: Depends entirely on the compiler. Example: SmallC/TinyCC only optimizes on the expression level and does not maintain values in registers.

* Portability? FASM: Supports ANY CPU/OS. We can define recognized CPU instructions and file formats. VC++/VS: WINDOZE ONLY! C/C++ has no standard way to write binary to the current file. FASM uses load/store/file.

* Development speed? FASM: Fastest assembler ever. All of my programs compile+execute instantly, in under 1 second on an average PC. VC++/VS: SLOW! 45+ seconds just to test run a program the size of CodeVu. HL compilers are getting slower. 20 years ago, BC++ 3.1 for DOS could compile small C/C++ programs in under 5 seconds.

* Size? FASM executable is only like 200K. All the latest versions of FASM+FASMARM+IDE+Z77 library easily fits on a 1.44MB floppy and that's a complete development package. VC++/VS: GIGABYTES!

* Standalone? FASM: Yes, runs anywhere with no setup (from memory card). VC++/VS: No, long confusing setup and additional compiler plug-ins. M$'s junk compiler packages take forever to download, install and setup.

* Separate linking/etc? FASM: No, just click Run or press F9 and that does it all. VC++/VS: Yes, separate steps and annoying confirmations everytime: "Are you sure you want save, compile, build, link, then... ?". Bah! "Run/Execute" should do all that.
Post 03 Jul 2013, 09:39
View user's profile Send private message Reply with quote
Turbo Lover



Joined: 22 Feb 2013
Posts: 32
Turbo Lover
solution:
stop using m$ and fasm. use GNU/Linux + emacs + gcc + libs instead
Post 03 Jul 2013, 09:49
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
The C/C++ developer must know his compiler (options, etc.).
My C++ projects (100 modules or more) compile in 10 sec on the 2-nd, 3-rd an so on compiler run.
1st compiler run -- it must do some additional work, like load its own DLLs and set up the pre-compiled stuff.
I use VS 2008. Produces excellent and small code.
You do not have to use the libraries, just code your own strcpy,strcmp, etc.
And of course, you need to know how to set up your headers.
Smile
Post 03 Jul 2013, 10:49
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17269
Location: In your JS exploiting you and your system
revolution
I'm not even sure a comparison is fair. fasm is an assembler for x86, whereas VS is a compiler for HLL. Isn't it kind of like apples to oranges? But never mind since it has been brought up let's explore it:

The only real point of comparison I can think of is the UIs of fasm and VS. fasm is lean and mean, whereas VS is fat and lazy. fasm is single purpose, whereas VS is trying to do everything.
Post 03 Jul 2013, 14:06
View user's profile Send private message Visit poster's website Reply with quote
TightCoderEx



Joined: 14 Feb 2013
Posts: 58
Location: Alberta
TightCoderEx
The single biggest thing that attracted me to FASM was that it is written in FASM. If I ever find something that is broken, or want add a feature, I could. Both FASM and FDBG compiled the first time without any problem.

Secondly, licencing because my ultimate goal is OS development. I have no aspiration or expectation that my works are going to become the next product to be used globally, but non the less, I don't want any restrictive caveats attached.

So the most significant points for me are;
    Utility
    Modifiability
    Ease of use
Post 03 Jul 2013, 14:41
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
FASM attracted me for those reasons:
1. No LINK utility
2. Super-fast assembling
3. API calls (MASM,TASM) were always going through some JMP table.
Post 03 Jul 2013, 16:25
View user's profile Send private message Send e-mail Reply with quote
Bob++



Joined: 12 Feb 2013
Posts: 92
Bob++
I will agree because it is a assembly forum and not a general programming one..

But the fact is nobody inside business care about this. I don't think that not even a crazy assembly lover will make SAS(software as a service) by using assembly language. It's just crazy! The executable is not even ensured to be fastest than even a hand-written assembly program where the assembler still helps doing some optimizations. But if they win in performance, who will keep updating a biggest assembly program? if it is hard in a HLL one, like C/C++, I don't need to say in assembly.

And maintenance, of course. Even outside business, in open source project, they need to update the software, fix bugs etc and who wants pain in this process? they use C language, and much C++ now.

Compilation speed - programmers in business(most part of VS users) prefer better final executable, and performance at run-time instead of small time in compilation speed. If you want to get small executable instead of better performance(that can make executable final big) just use VS's flags.

Any C compiler that I know can make a standalone. You don't need to link to libc even with gcc compiler.
Visual studio there's too the FX button that just do all compilation without ask anything. I don't know really what are you speaking.
Post 03 Jul 2013, 17:04
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
revolution wrote:
fasm is lean and mean, whereas VS is fat and lazy. fasm is single purpose, whereas VS is trying to do everything.


VS is getting slower since WPF is used in the IDE.
In this case, I think VS 6 is the best.

On the other hand, I definitely like the idea of VS-like IDE for FASM.
WinAsm is the closest contender in my mind. It lacks integrated debugger and profiler, though.

Smile
Post 03 Jul 2013, 22:29
View user's profile Send private message Reply with quote
Bob++



Joined: 12 Feb 2013
Posts: 92
Bob++
TmX wrote:
revolution wrote:
fasm is lean and mean, whereas VS is fat and lazy. fasm is single purpose, whereas VS is trying to do everything.


VS is getting slower since WPF is used in the IDE.
In this case, I think VS 6 is the best.

On the other hand, I definitely like the idea of VS-like IDE for FASM.
WinAsm is the closest contender in my mind. It lacks integrated debugger and profiler, though.

Smile


IIRC, VS 08 doesn't use WPF. It's great too! I like so much WPF, btw.
Post 04 Jul 2013, 01:21
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
Quote:
Isn't it kind of like apples to oranges?
It is an unfair comparison, but FASM+ML and C/C++ are the only 2 choices I have for creating an ARM OS on embedded systems.

Quote:
biggest thing that attracted me to FASM was that it is written in FASM
Not only is it written in ASM, it's the most efficient assembler source code I've seen.

I've been working on a macro language that resembles C/C++. It will generate code for X86+ARM and support multiple OSs. What should I name it? C-ML? ASM++?
Code:
; example 1...

include 'c'

int main()
 printf("Hello")
 return 0
endf

; example 2...

include 'c'

int i
char name[32]

int main()
 puts("Enter your name: ")
 gets(name)
 strrev(name)
 printf("Your name backwards is: %s", name)
 for (i=0, i<10, i++)
  puts("Index: %d", i)
 endf
 return 0
endf

; example 3...

include 'c'

int i, *p
char *message="Pointer Example"

char *strcpy(char *a, char *b)
 .while *b
   . *a++=*b++
 .endw
 . *a=0
 return a
endf

int main()
 . p=&i    ; p = i's address
 . *p=123  ; assign i indirectly

 printf("Address: %xh. Value: %d", p, *p)

 . p=malloc(1024)
 .if p=NULL
   puts("Error: Memory allocation failed")
   return 0
 .end
 strcpy(p, message)
 puts(p)
 free(p)
 return 0
endf    
Quote: Writing useful macros in FASM is not the same thing as using a HL compiler
Post 04 Jul 2013, 02:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17269
Location: In your JS exploiting you and your system
revolution
uart777 wrote:
... FASM+ML and C/C++ are the only 2 choices I have for creating an ARM OS on embedded systems.
ARM.com has some tools for download. Both assembler and HLL compilers.

But one thing to realise here is that assembly and HLL are not mutually exclusive. We can use one, or the other, or both. Everyone has different needs and goals.
Post 04 Jul 2013, 05:41
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Just a few comments from a compiler aficionado (who sadly hasn't written his own yet):

Macros: These can actually heavily slow down FASM, if you overdo it! And there's no reason you can't use an external preprocessor. (That's what they did years before cpp was standardized, and a lot of other languages don't have built-in preprocessors.)

Optimization: This is difficult for anybody. It's hard to support multiple cpus, even across the same family. A few are general enough to work anywhere, but mostly it's cpu-specific (arcane, hardcoded, expensive). Honestly, in most cases, compilers don't even barely try, presumably out of despair.

Portability: With the right tools and libs, you can retarget MS VC, it's been done several times (e.g. HX for DOS). Indeed, they don't really intend different host or target for strategic reasons, but back in the day they did support other OSes (mostly OS/2 and DOS) with their various compilers.

Development speed: You can still use old DOS compilers on modern machines, I do it all the time! Smile If all you care about is speed, you'll have to be careful about several things: disk access, available RAM, even things like precompiled headers (or suitable language that doesn't have that problem), multi-pass vs. single pass, etc. Keep in mind that half (but not all) of the speed slowdown is an attempt to optimize. If you disregard all optimizations, it should speed up (and indeed one-pass usually isn't the best regarding optimizations, though it is much faster overall, e.g. TinyC).

Size: The .EXE is only half the story. To compare to others, you'd still needs tons of wrappers, libs, headers, tools, etc. for all the billions of features of modern computing. And BTW even the OberonOS (back in the day) could fit on floppy with its own compiler. You may wish to read Wirth's 1995 (!) Plea for Lean Software.

Standalone: Most people don't have an interest in static binaries, though they do exist. And again, if you disregard all the modern dependencies but stick strictly to the (minimal?) standards, you could cut out most bloat (but also make things potentially more difficult). Admittedly, MS VC is too big, but there are literally dozens of compilers that are much more reasonably sized.

Separate linking: If you don't need external linkage, use an interpreter. But that has its own drawbacks (usually slower speed, crippled modularity).
Post 09 Jul 2013, 00:57
View user's profile Send private message Visit poster's website Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
Quote:
Macros: These can actually heavily slow down FASM
Depends on how you implement them. You all use macros: struct, proc, invoke, stdcall, etc. Only difference is, you use macros that are predefined by FASM (\INCLUDE\) and I write my own. Again, my programs compile in about 1 second on a modern PC (even on my I32 netbook).

Quote:
Development speed: You can still use old DOS compilers on modern machines, I do it all the time!
Cool! Smile I love the old C/C++ DOS compilers (Borland, Turbo, etc), too, they're good for practice - but they're old and outdated now Sad So, let's make a better HL compiler.

Quote:
Optimization: ... It's hard to support multiple cpus, even across the same family.
Bah! Not hard for me. My latest version of Z77 supports 3 CPUs: X86, ARM and MIPS. Of the 3, I would say that ARM is the most complex CPU despite that it's categorized as "RISC". That doesn't apply to the newer ARM CPUs. ARM is real hardcore, not for the faint of heart, only for the strongest ASM programmers.

Quote:
Size: The .EXE is only half the story. To compare to others, you'd still needs tons of wrappers, libs, headers, tools, etc. for all the billions of features of modern computing
No, I do not need "wrappers, libs, headers, tools, etc". As an embedded systems programmer, I write my own machine code, executables, libraries, etc. Have you seen my Star-OS?

Star-OS: http://board.flatassembler.net/topic.php?t=15534
CodeVu: http://sungod777.zxq.net/z77_rpi.zip

Previews of my recent programs, all created in FASM. I'm 100% FASM programmer 4 life:Image


Last edited by uart777 on 21 Jul 2013, 10:03; edited 1 time in total
Post 09 Jul 2013, 04:34
View user's profile Send private message Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
uart777 wrote:
Cool! Smile I love the old C/C++ DOS compilers (Borland, Turbo, etc), too, they're good for practice - taught my daughter C/C++ when she was 6 years old, she's 17 now and studying "Computer Science" and game programming


Are you serious? Cool, good for you both!

_________________
There's nothing special about it,
It's either there when you're born or not.
Post 09 Jul 2013, 15:35
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Sorry for minor delay, it required some thought (though I'm still unsatisfied with my answers, oh well).

uart777 wrote:
What do you know about expression parsing and ASTs?


Not much, I haven't fully studied various Wirth (et al.) books yet. Simple expression, term, factor ... binary trees, etc. It's all a bit complicated for me. A compiler, even a simple one, doesn't get developed overnight! (PL/0 for the win!)

Quote:

Quote:
Macros: These can actually heavily slow down FASM
Depends on how you implement them. You all use macros: struct, proc, etc. Only difference is, you use the macros that are predefined by FASM (\INCLUDE\) and I write my own. Maybe you think they're the best and only way and no one can improve your Hutch bible. Again, my programs compile in about 1 second on a modern PC (even on my I32 netbook).


Simply put, I didn't mean macros are bad, just vaguely remembering one guy that had some macros that slowed down FASM to like 30 seconds (or more) per assemble. (If I knew what thread it was under, I'd link to it here, for completeness.)

The main problem I have with macros is that I admittedly know nothing about them, never majorly interested. For one, the idea that every assembler has a different macro engine makes it more annoying (esp. trying to convert between tools). There's always external preprocessors, of course, but honestly for my very simple stuff I don't need it. Just sometimes people overcomplicate things for little (if any) gain, and that is always frustrating.

Quote:

Quote:
Development speed: You can still use old DOS compilers on modern machines, I do it all the time!
I love the old C/C++ DOS compilers (Borland, Turbo, etc), too, they're good for practice - but they're old and outdated now. So, let's make a better HL compiler.


Sometimes old is the best! But my main point was that you can use a different compiler (at least for minimal standard console and file I/O work) without all the extra IDEs, debuggers, libraries, etc. (And some of those Borland compilers were fast due to one-pass, minimal optimizations, etc.)

It doesn't have to be DOS, but my point was that even "simple" OSes have "simple" compilers (or at least simpler) that don't take hours to rebuild stuff. And I'm somewhat of a DOS nut, so I have about a dozen different C compilers, some of which are still updated. Though, again, it depends on what you're trying to do (graphics? networking?) and for what target OS, what language dialect, etc. (Adding all of these things can bloat up pretty quickly. Compare GCC 2.7.2.3 to 3.4.6 to 4.8.1.)

There too many differences to mention, so even if I say that "installed" size of a "C/C++ compiler for DOS" (usually with extras, e.g. GNU stuff needs a fair few POSIX tools and libs) can vary between 1.2 MB and 171 MB (average 21.4 MB), of course you're right that you don't "need" that much just to do "reasonable" programming. But it depends on features needed, experience, and how low-level you're willing to go, etc.

I assume you're aware of Forth and how it traditionally has been equally small and capable in this regard. But even that can widely vary among implementations.

Quote:

Quote:
Optimization: ... It's hard to support multiple cpus, even across the same family.
My latest version of Z77 supports 3 CPUs: X86, ARM and MIPS.


I meant that I'm vaguely unimpressed with those compilers (e.g. GCC) that are too complicated because they added so much mandatory internal infrastructure support for various optimizations. Normally a compiler is supposed to be well-designed enough to keep the language front end(s) portable, neutral, and separate from the more-complicated, cpu-specific backend (code generation).

I think people unfairly focus too much on optimizations instead of bootstrapping and portability. (I always feel disappointed that HLLs are misused to deliver barely any, if at all, superior portability compared to pure assembly.) I just hate seeing programs that don't run on certain OSes because of programmer sloppiness (or ignorance), even across the same cpu family (x86!).

Quote:

Quote:
Size: The .EXE is only half the story. To compare to others, you'd still needs tons of wrappers, libs, headers, tools, etc. for all the billions of features of modern computing
No, I do not need "wrappers, libs, headers, tools, etc". As an embedded systems programmer - I write my own machine code, executables, libraries, etc.


99% of programmers don't write to the bare metal anymore (freestanding). In fact, it's not always possible (no public specs, patents, whatever). While I wish it were easier, it's not, hence the need (and 1000x moreso the want from the general public) for more and more features, which means more libraries and tools and APIs and dialects. Sure, you can limit yourself, nobody's stopping you, but overall there's a reason that MSVC is super bloated: it tries to do too much.

Quote:
I'm 100% FASM programmer 4 life. Thanks Tomasz! Smile


I've been on an HLL kick (off and on) for about three years. Keep in mind that I'm a very very limited hobbyist only, but still, it's very interesting. Unlike vid (or at least my imperfect impression of him), I've not abandoned assembly. He made some points, but if anything, I still think assembly is overlooked and that HLLs don't solve half the problems they create ... sometimes. (Well, HLLs can use FASM as backend too, heh.)

The simple truth is that computers are just too complicated. Well, you don't need my rants, but it just frustrates me. It's just too much, and things change too fast, especially for (IMNSHO) dumb reasons: money, ego, politics. So we're stuck with ten tons of incompatible dialects, APIs, libs and lots of (minor but annoying) problems. I think it's unavoidable these days, when everyone wants to chase every latest feature. Well, we can't fix the world, we can only control ourselves.
Post 12 Jul 2013, 18:58
View user's profile Send private message Visit poster's website Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
Can't compare ASM and HLLs. Different purposes.

FASM is great assembler for when you need low level code. Wouldn't use FASM for tiny dead-line business application.
Post 21 Jul 2013, 03:59
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
OzzY wrote:
Can't compare ASM and HLLs. Different purposes.

FASM is great assembler for when you need low level code. Wouldn't use FASM for tiny dead-line business application.


Well, fortunately the OP states the reason later:
Quote:

It is an unfair comparison, but FASM+ML and C/C++ are the only 2 choices I have for creating an ARM OS on embedded systems.
Post 21 Jul 2013, 04:39
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
Entire OSes and space system control systems have been written in C and higher level languages.

This is one of the most ignorant threads this forum has ever seen. It can be productive and educating to keep this naive attitude as it will provide motivation to learn assembly and innards of computer organization, but do not get caught in it.
Post 01 Aug 2013, 09:18
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
uart777 wrote:
WHY I USE FASM? AND NOT C/C++/VC* [b]Portability? FASM: Supports ANY CPU/OS.


Supports any CPU/OS? Really? That's news to me.

But yeah assembly rules! And fasm is awesome Cool

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 01 Aug 2013, 19:22
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
rugxulo wrote:
Just a few comments from a compiler aficionado (who sadly hasn't written his own yet):

Macros: These can actually heavily slow down FASM, if you overdo it! And there's no reason you can't use an external preprocessor. (That's what they did years before cpp was standardized, and a lot of other languages don't have built-in preprocessors.)


There is a big difference in capability and usefulness between native (built-in) preprocessors and external add-ons. For one thing, a native macro facility can access symbol table information that's not available to external processors IBM's assembler and Pl/I are two examples of languages where the macro language is dramatically better than any possible external alternative, and especially their assembler just wouldn't be nearly as useful without it. In fact, the whole OS is based on assembler macros just to give you an idea how integral and useful that facility is in that environment. PL/I's preprocessor was ahead of its time then and now, but it's been a long time since I used it and can't remember any specifics other than to mention it's well known and well-documented in case anybody wants to look into it. The doc is freely available for it and their assembler.

UNIX preprocessors like cpp and m4 are almost worthless except for environmental tests. Use them for anything else and you'll quickly start ripping your hair out. The reason people haven't done anything better in UNIX is mostly laziness and complacency and the UNIX attitude of each piece of software doing only one thing (barely). Really, UNIX tools are no example of anything except How Not To Design Programs (tm).

Macros in assembler should be about two things. One they should provide useful abstractions to the programmer and maintainers so that things are always done the same way in code over a large program. For example if you need to manage control blocks then if you write good macros everybody who manages that control block uses the same API. If the code needs to be changed you fix it in one place. OTOH fancy macros or tricks do more harm than good. People should never write macros that will only generate a gigantic program or be used once in a big piece of code except for prolog/epilog since they're generally used. The second thing macros should be about is writing code instead of you having to write it. My programs are much clearer, the source is significantly shorter (before expansion) and much less error-prone because of judicious use of macros that add clarity, standardize ways of managing resources, and give clear APIs. Performance shouldn't be a consideration and if it is, the macro language probably needs to be fixed.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 01 Aug 2013, 19:40
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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.