Clearly ASM does have advantages in many applications that require "to the metal" development and in areas of optimisation.
Universities and organisations however seem to have pushed ASM out of the door, given that this is the case, does ASM have a future outside of it's niche areas?
People would classify these tasks as "difficult" if done in pure ASM:
* Scripting
* Writing medium to large programs

How do the people here feel about this?
Are there any disadvantages in writing a program fully in ASM compared to C++ or Java? Keep in mind I am not talking about the advantages of Java or C++ over ASM, I realise that you can use the macro system to largely write OOP programs in ASM.

My feeling is that ASM is limited in today's world purely as an optimisation tool, something that high level and even scripting level languages would link to in order to be performant at some operation.
Posted on 2008-03-05 02:47:32 by Kruno

People would classify these tasks as "difficult" if done in pure ASM:
* Scripting
* Writing medium to large programs
Scripting can't be done in assembly because scripting is always done in a scripting language.  Writing medium to large programs is slower more than difficult because higher level languages are automatic code generators and the code is somewhat easier to read.  But if you are used to coding in assembly, it can be almost as easy to read as any HLL.

My feeling is that ASM is limited in today's world purely as an optimisation tool, something that high level and even scripting level languages would link to in order to be performant at some operation.
This has all been covered too many times in the past.  HLLs make coding faster at the expense of larger programs and perhaps sloppier coding and maybe the need for more tools to keep it all together.
Posted on 2008-03-05 07:45:38 by drhowarddrfine


People would classify these tasks as "difficult" if done in pure ASM:
* Scripting
* Writing medium to large programs
Scripting can't be done in assembly because scripting is always done in a scripting language.  Writing medium to large programs is slower more than difficult because higher level languages are automatic code generators and the code is somewhat easier to read.  But if you are used to coding in assembly, it can be almost as easy to read as any HLL.]


nonsense.. scripting can be done in assembly, its just not that common.. and the task rating is purely relative to the skill set of the coder...
Posted on 2008-03-05 08:01:16 by evlncrn8
How do you script in assembly?
Posted on 2008-03-05 20:32:54 by drhowarddrfine

How do you script in assembly?

Bytecode, calling a proc from a table, or executing script text that looks very much like asm code.

Kruno: without asm, you wouldn't be seeing modern console games that constantly push the limits, or scientific projects like F@H that need to squeeze-out max performance. And everywhere else, ... you'd be constantly seeing projects getting canceled when OOP-brainwashed kids start encapsulating everything instead of doing the right thing; constantly making their own assumptions on how the cpu magically executes their code/script. It's like running in the dark - rarely a good thing. I've seen enough times teams of HLL/script coders being given a task, each coder expressing their assumptions on how code works, each trying to drag everything to circle around their assumptions. .

At least by knowing asm, having experience in optimization with asm, and knowing what your compiler produces - you can code most of your project in a HLL. And then optimize the critical parts in asm. You'll also be seeing many new ways to design/implement your project (as you know how the cpu works), often leading to even faster and bug-free completion of a project.

The 3 disadvantages of making a project completely in asm are:
- floating point arithmetic - it's hard/slow to type and bug-prone when you're inexperienced.
- multidimensional arrays - it's not a piece of cake, but at least not as hard as the FPU
- register preservation has to be taken care of, or you can introduce a bug. Once you decide on a style/standard, it becomes a breeze.
Everything else can be handled easily with macros.

Once you're experienced enough, only the FPU code can be a bother.
Posted on 2008-03-05 22:00:30 by Ultrano

How do you script in assembly?


The closest I can conceive of is by using macros.

Beyond that, scripting languages and assembly language are on opposite sides of the programming spectrum :|

There will always be a need for someone who knows how some piece of code is directly affecting the underlying machine. However, how many are needed is a different question altogether.

This reminds me of the separation between Analog and Digital electronics, the difficultly between the two and the amount of designers/developers there are.


Are there any disadvantages in writing a program fully in ASM compared to C++ or Java? Keep in mind I am not talking about the advantages of Java or C++ over ASM, I realise that you can use the macro system to largely write OOP programs in ASM.


Time, price, quality... pick any two ;)
Posted on 2008-03-05 22:05:39 by SpooK
I've written parsers and runtime parsers (interpreters/script engines) in asm before, its just another form of input data. I really don't see the problem.
Posted on 2008-03-07 02:44:27 by Homer
Why coding in ASM?

Strangely this question is always asked by coders that don't write programs in ASM.
The only advantages they see coding in ASM are speed and size.

Here are another ones:

Creating Algorithms is easy.
You are not required to learn a complicated syntax from a complicated programming language. There are only few commands the CPU can understand. You have to deal with them. If the program doesn't work the way you like, it's your fault - see "debugging is easy".

WYWIWYG - What you write is what you get.
No High-Level-Compiler alters the written code or adds malicious one because of dubious "optimizations". Only you are the optimizer.

Data structures are easy.
Look into disassembled code from a high level language compiler and you will see that sophisticated data structures are often being reduced to a simple form.
Use simple data structures to make the algorithm more comprehendable. The versatile addressing modes of the x86-CPU are very comfortable.

Debugging is easy.
Because you are conform with the assembler syntax, you are also conform with the disassembler syntax from any debugger. Just put an "INT 3" at the desired position in your source code and the debugger will stop there if you run the program.

Creating binaries is easy.
You don't have to install a licence restricted multi mega byte super compiler which nestles into your system and buckles all interfaces. A text editor, an Assembler-EXE and a Linker-EXE and are sufficient.
Posted on 2008-06-02 22:42:02 by TasmDev
There is more.

Asm has been evolving for some time now, through the extended functionality of each generation of assemblers.

Now asm is evolving though an entirely new(ly-reinvented) programming paradigm that is becoming known as "OOP-asm" (not to be confused with Randy Hyde's 'HLA - HighLevel Assembly' language, which is a standalone preprocessor that emits asm sourcecode).

This paradigm has various advantages when compared to various high and/or lowlevel languages - it allows the programmer to take advantage of the benefits of each school of code as it suits them, and in a given context they might choose to lean the code one way or the other. But at the end of the day, its being compiled by an ASSEMBLER - so you have a lot more (full asm) control over register use and choice of operators, where and when you see fit.

I repeat - Asm is EVOLVING - it is not a dead NOR a fixed language - it is NOT machinecode - it is as dynamic and symbolic as we WANT it to be - and you HLL purists please note that OOPASM has similar development times, with typically faster and smaller binaries, even without careful optimizing.

So much for the new wave :P

Posted on 2008-06-03 07:38:01 by Homer