Introduction to the Assembly Rebirth ..
After the oncoming of Windows 3, Assembly had been considered a dead Language by many programmers (including myself). During the years 1995-2000 a couple of pioneers achieved forcing open the closed door. In between time, any request sent to M$, for 'How to program in assembly under Windowz?' regularly got the same answer: 'Impossible! Windows being a C interface, it must be programmed in C...'.
The interest of dominant Companies for killing Assembly is quite evident:
They can't sell anything to assembler programmers.
Particularly not illusions.
Despite the recent rebirth, the disaster is still actual, as we can see each time we read some papers with titles like [Why Assembly] or [Assembly advantages]. Yet now, it is regularly stated that Assembly is interesting because of its capacity at producing Small and Fast Code, ... by HLL programmers making use of Asm Routines...
The sub-line of such claims is always that Assembly is just good for producing inline routines in order to improve the HLLs productions performance quality and to overcome their limitations, but that writing Applications in Assembly would be a strange idea coming from guys unable to use ''the proper tool for the proper thing''.
These ideas are basically unfounded and stupid from every point of view:
If Assembly interest is the speed of produced Code, with the actual Processors performances, the argument is very weak, and the Processors evolutions will go on and on, pushing to stupid and dirty programming methods.
If Assembly interest is at the size of produced Code, the argument is completely ridiculous, given the actual Hard Disks capacities and given the modern OSes Memory Manager's performances.
Another commonly expressed opinion is that Assembly is more difficult, more error prone and more dangerous than HLLs. This is partially true for the real beginner, who has to learn, at once, a lot of things, (like with any programming Language), plus the 20 Mnemonics we regularly use in Assembly Applications programming, plus the Asm Data Managements. With actual Assemblers and actual OSes, the Assembly ''difficulties'' are less and less true. After the first learning steps, not only has this turned false, but one can even see that Asm is often times easier than HLLs.
Generally speaking, actual Assembly Sources tend to be much more readable than, say, the usual 'Write-Only' cryptic C and C++ Sources. Also, because of the fact that Assembly offers a One-to-One correspondence between what you write and the outputted Code, debugging is made a hundred times easier and much faster in Assembly than with any HLL.
The real difference between Assembly and HLL programming is not that at all, that an Assembly written Application would be an optimized version of what an HLL could ever output.
The first point that makes some difference is about Strategy_Optimization. Why can't HLL programmers do real Strategy Optimizations ? Simple: When you do not have the real thing under your eyes, you simply do not know what you are really doing.
The RosAsm Disassembler, for example, is, more or less, 120 times faster than other Disassemblers and 20 to 50 times smaller,... this is not because I am a genius and/or because the other HLL Disassemblers Authors are stupid. This is because, when writing with RosAsm, I can see and I can know what I am really doing, from the bottom-end to the top-end of the logical actual Application building process.
This last point is the important thing. The speed and size gains are nothing but side effects, that will have lesser and lesser interest in the future, and that have a poor direct relationship with the chosen language, but strong relationship with the strategy visibility offered by the language.
One another great point with Assembly, compared to HLLs, is that Assembly has no organization convention. HLLs authors are telling you how to write. We, Assembly programmers, are telling the Assembler what to do. Therefore, we are responsible for our own definition(s), our own organization (s), our own style(s) and choices. This makes some significant difference... Just like the difference between the wolf and dog, freedom and containment, Anarchy and Fascism.
Something even more important than freedom is achieved by this convention lack: HLLs (typically C) force the programmers to always do the things in the same way, a bit like a mentally diseased person who would always answer the same sentence to any question.
In the real programming world , there is no such thing like a universal answer to the various problems we may encounter every day. What is good here may be stupid there. This flexibility, is a key for solving problems in Assembly, depending on the problem and not on the Language, is really nothing but what one usually calls... Intelligence.
The real question -out of market concerns- is now 'Why HLLs?'.
By definition, HLLs can do nothing but applying masks upon Assembly. Masks imply limitations, lesser access to the Asm 'reality', restrictions, illusions of portability, illusions of ease of use, which have always a heavy cost, when one has to force the closed black boxes. The price you don't pay, first, you pay last. Most often... at a much higher price.
Added to this, if we have to learn the basics of Asm, at the end, just to push-up the quality level of HLLs produced Applications, then, why use HLLs at all ?
Once you know Assembly programming. you are -unless you want to control the Processor electric impulsions- in the 'true thing' and you can do anything you want, with no more development time and no more difficulties than with any HLLs.
An important point, that misleads a lot of people, is that the HLLs so called ease-of-use, is usually not a characteristic of the Languages themselves, but is a characteristic of the user interfaces. If you may get a running DataBase in a couple of Clicks with Borland Pascal, this fact has zero relationship with the Pascal Language.
This is nothing but a ''Wizard'' output, and there is no reason that an Assembler could not be also featured with such Interfaces and Wizards. The real fact is that actually, there is no such Visual Components editor implemented in any Assembler, but despite the difficulties, the Assembly Rebirth will necessarily have to go to that point, and it will.
Finally, all actual Assemblers, include good features authoring HLL as writing Styles. These High Level Assembly Styles tend to turn Asm Sources into as easy to read sources as good old time Basic. So, what ? In some way, the remaining difference between HLLs featured with inline assembly, and High-Level-able Assemblers, is that the first ones are 'Top-Down', whereas the second ones are 'Bottom-Up'.
Top-Down is nothing but just a weird idea: Nothing ever worked that way in any natural world.
All programmers who really know Assembly seem to be of this opinion, that Assembly is perfectly well designed for producing full Applications:
Among the last three written Assemblers, two of them (RosAsm, FASM), directly output Applications. Two of them (GoAsm, RosAsm), output only PE Files. So it seems that we all three authors consider that there is absolutely no reason for not using Asm for building full Applications. Needless to say, all three Assemblers are written in Assembly and RosAsm, being auto-compiled, offers a two Megas Octets Source demonstration.
Nevertheless, the Assembly rebirth will remain a long journey, as we will have to slowly rebuild a user base from zero, mainly with real beginners.
Several facts will dramatically slow down this rebirth. The first one is, of course, the existence of a group of HLLs programmers using and defending Microsoft MASM, which, alas, is actually the Main-Stream, and which, alas, will go on misleading beginners for several years, wasting a lot of effort on a dead end road. The second fact comes from us, the Assemblers' authors, as we have been unable to federalize our works. Not only several Projects are running on different roads, but, even worse, despite my repeated efforts, we have never been able to define any generally accepted syntax common base (!!!...). A third and recent event will delay the Assembly Rebirth for several years:
The oncoming of HLA (an HLL Pre-Parser to other Assemblers, that its Author calls 'An Assembler'), and the book publication of associated Tutorials, are going to dry out the tiny flow of Assembly new comers for all the serious Assemblers Projects.
... So that the upcoming situation is actually as follows:
1) Very few Assembly Programmers.
2) 50% of those very few, lost for ever to MASM.
https://en.wikipedia.org/wiki/Microsoft_Macro_Assembler
3) The remainder, divided into GoAsm, RosAsm, FASM and NASM, ...
4) Among the new Assemblers, only two (NASM and RosAsm) are GPLed and open to collective developments, while the others are clearly ''Anti-GPL'' (!?!?!?...).
So, most efforts go directly into the dust bin, and, if an Anti-GPL Project would rise to success, in the coming years, all of the work would have to be re-written again (!!!...).
Well, now, let the better win, but... what a waste!
~~~~~~~