Anyone else think assembly is (mostly) useless?

[c4757p]

Seen this? Looks interesting, but I haven't tried it yet.

Hey! They stole my idea! 

Actually, no, I haven't seen that. I'm not very familiar with GCC.

Also interesting is LLVM/Clang because the linker is the part of the system that emits actual machine instructions (and it has all the definitions to look at).

Yup. I actually had been using LLVM to emit the machine code, though I didn't use too many LLVM-specific features as I wanted to be portable to other systems (LLVM was reasonably new at the time and I didn't know if it would be sticking around). The goal was initially to use the LLVM-based system as a "prototype" of just the language, then migrate to my own proper backend - though if I were designing it now, I'd probably stick with an existing backend like LLVM or GCC for the built-in multiple platform support, rather than toiling away coding my own backends for each architecture...

[andyturk]

Yup. I actually had been using LLVM to emit the machine code, though I didn't use too many LLVM-specific features as I wanted to be portable to other systems (LLVM was reasonably new at the time and I didn't know if it would be sticking around).

LLVM is super cool. Apple seems to be betting the farm on it, so I doubt it's going away any time soon.

I wonder what the assembly die-hards in this thread would have to say about LLVM Intermediate Representation (IR)... A machine with an infinite number of write-once registers, named types, array instructions, and those wacky phi things.

PS. That was rhetorical. I know what they'd say... 

[AlfBaz]

I wonder what the assembly die-hards in this thread would have to say about LLVM Intermediate Representation (IR)... A machine with an infinite number of write-once registers, named types, array instructions, and those wacky phi things.

ARE YOU SERI... %-B

PS. That was rhetorical. I know what they'd say... 

I go home now

[JuKu]

A flame bait: I think that anyone claiming that hand coded assembly is faster or smaller than fully optimized high-level complied code is either
-talking about a few isolated lines in a very specific situation
-doesn't have a very good idea about how good a good compiler really is
-is using crappy tools
-or doesn't know how to use the tools.

[MrPlacid]

A flame bait: I think that anyone claiming that hand coded assembly is faster or smaller than fully optimized high-level complied code is either
-talking about a few isolated lines in a very specific situation
-doesn't have a very good idea about how good a good compiler really is
-is using crappy tools
-or doesn't know how to use the tools.

As my first programming project,  I have written a point of sale software in assembly which consists of two files: the cash register (88.0KB) and the inventory(75.5KB). It is blazingly fast. It is in actual use everyday running off a netbook at our place. In another store, it runs off a desktop.

Though, I agree assembly is mostly useless nowadays. But give assembly its respect.

[BravoV]

Though, I agree assembly is mostly useless nowadays. But give assembly its respect.

+1  , declaring it is utter useless is just a stupid & ignorance "attitude", and worst keep defending that statement is definitely an attention whore/troll.

[amyk]

A flame bait: I think that anyone claiming that hand coded assembly is faster or smaller than fully optimized high-level complied code is either
-talking about a few isolated lines in a very specific situation
-doesn't have a very good idea about how good a good compiler really is
-is using crappy tools
-or doesn't know how to use the tools.

To my knowledge there's no easily available HLL compiler out there that can do
- overlapping opcodes
- self-modifying code (not for ROM use, but I'm talking in general)
- non-HLL-like tricks with the stack
- dynamic code generation (similar to SMC, but for bigger pieces)
- multilevel returns (not exactly the same as exceptions - see below)
those are just some of the techniques an Asm programmer can use for size optimisation. As I said above, an HLL compiler has standards it must follow (e.g. calling conventions), it is difficult for a programmer to express certain assumptions that could lead to optimisation, and the compiler can't easily infer these assumptions since it might break other code where they don't hold. The simplest example I can think of is having a function that can return not to its caller, but to the caller of its caller ("2-level return"). In Asm this is just a few stack manipulations. In C you can only do this with setjmp/longjmp, but that's already additional code being generated. In C++ you can use exceptions, but that entails a whole lot more stuff being generated. I'm not saying it's impossible for a compiler to recognise this and generate the same code as the human, but currently no compilers do it. With Asm you're not bound by the conventions (restrictions) of the higher-level language, you can do whatever the machine can.

Look at the demoscene, lots of examples of extreme size optimisation there.

[jpb]

A flame bait: I think that anyone claiming that hand coded assembly is faster or smaller than fully optimized high-level complied code is either
-talking about a few isolated lines in a very specific situation
-doesn't have a very good idea about how good a good compiler really is
-is using crappy tools
-or doesn't know how to use the tools.

To my knowledge there's no easily available HLL compiler out there that can do
- overlapping opcodes
- self-modifying code (not for ROM use, but I'm talking in general)
- non-HLL-like tricks with the stack
- dynamic code generation (similar to SMC, but for bigger pieces)
- multilevel returns (not exactly the same as exceptions - see below)
those are just some of the techniques an Asm programmer can use for size optimisation. As I said above, an HLL compiler has standards it must follow (e.g. calling conventions), it is difficult for a programmer to express certain assumptions that could lead to optimisation, and the compiler can't easily infer these assumptions since it might break other code where they don't hold. The simplest example I can think of is having a function that can return not to its caller, but to the caller of its caller ("2-level return"). In Asm this is just a few stack manipulations. In C you can only do this with setjmp/longjmp, but that's already additional code being generated. In C++ you can use exceptions, but that entails a whole lot more stuff being generated. I'm not saying it's impossible for a compiler to recognise this and generate the same code as the human, but currently no compilers do it. With Asm you're not bound by the conventions (restrictions) of the higher-level language, you can do whatever the machine can.

Look at the demoscene, lots of examples of extreme size optimisation there.

Most of those techniques seem to be designed to produce write only code - i.e. not very maintainable.  If space is so tight that you need such techniques what do you do if you need to add a feature later on?
For example, a two-level return would normally just be done by a flag return in c, i.e. the normal return would be 0 and a two level return might be indicated by a non-zero value and the calling routine would use
if(y=f(x))return y;
of just if(f(x))return;
So you save a pull and a push but need extra stack manipulation.

I'm not denying that there is a place for some clever stuff, for example I like the various techniques for swapping integers without using a third such as
i = i^j;
j = i^j;
i = i^j;
but though I've known it for years and have occasionally used it in code for fun, I've never been in a position where I've needed it.

A good book on such stuff is Hackers Delight, which is nothing to do with breaking into computer systems but is all about bit manipulation to do clever stuff.

[Kremmen]

To my knowledge there's no easily available HLL compiler out there that can do
...

And then there are those who would consider those "neat tricks" either anathema to proper SW construction or at best irrelevant to anything that matters. I don't intend this as offense but honestly, most of those techniques are considered practices to avoid. Why? - because they break the principles of tractability, verifiability, maintainability and portability to name just the most obvious.
Honestly, this list is much more a set of arguments why you should steer well clear of assembly. I am almost sure that if you checked, nearly all of the principles those items suggest would be listed as "coding horrors" in Code Complete http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670, still IMO one of the best practical guides for SW construction. Sure, CC discusses entirely different problem domains than embedded apps, but my view is that the principles outlined there should be brought to embedded development as much as possible, instead of the reverse.

Sorry, but once again one is reminded of Mel http://www.cs.utah.edu/~elb/folklore/mel.html

[BravoV]

If space is so tight that you need such techniques what do you do if you need to add a feature later on?

It happened and will happen again, and if thats your agument, then how HLL is going to help ?

I would imagine the boss will say, "Dude, we already living at razor thin margin here, listen, unless you are going to work unpaid for years, then do the mcu/ram/whatever upgrade as you whined proposed, how is that sound ?"   

[mikes]

And then there are those who would consider those "neat tricks" either anathema to proper SW construction or at best irrelevant to anything that matters. I don't intend this as offense but honestly, most of those techniques are considered practices to avoid. Why? - because they break the principles of tractability, verifiability, maintainability and portability to name just the most obvious.

That's a circular argument. Those principles were developed to apply to high level code. Really, you expect assembly to maintain the principle of portability? Meh.

[jpb]

If space is so tight that you need such techniques what do you do if you need to add a feature later on?

It happened and will happen again, and if thats your agument, then how HLL is going to help ?

I didn't suggest a HLL would help. My point was simply that given that software development is expensive and slow and speed to market is important and generally hardware is relatively cheap it makes more sense to use hardware with sufficient RAM/ROM  and develop the software as efficiently as possible without battling against self-imposed constraints.

If you're constrained by power requirements, size generally (such as fitting things into a wrist watch) then you might need to use every trick available to fit code in. Even so I'd say that you'd be better off prototyping using a HLL and then see how much you need to reduce size, increase speed and convert some code to assembler.

I can see that many people would enjoy the challenge of making code as small as possible, and perhaps some might want to deliberately obfuscate the code to deter reverse engineering but generally it is not a good way to produce software that will need to be maintained and updated over time.

[Kremmen]

And then there are those who would consider those "neat tricks" either anathema to proper SW construction or at best irrelevant to anything that matters. I don't intend this as offense but honestly, most of those techniques are considered practices to avoid. Why? - because they break the principles of tractability, verifiability, maintainability and portability to name just the most obvious.

That's a circular argument. Those principles were developed to apply to high level code. Really, you expect assembly to maintain the principle of portability? Meh.

Circular? No of course it isn't circular. I don't see the use of assembly maintaining practically any modern SW construction principles, that is precisely why i advocate minimizing its use. There are limited, very specific cases where its use is warranted or indeed, unavoidable. But as a general purpose programming language its days are long gone.

[AlfBaz]

tractability

pft, to bad we don't own a farm

[gautamdamodar]

-1

[jmc2000]

Yes, assembly programming is most useless compared to programming in more maintenance freindly high leve programming languages such as C. But like it or not, you need to understand assembler when debugging a programme, even to the point of highlighting a bug in the compiler itself!

That being said, a good softwarre programmer will be at ease with programming in assembler.

[kt315]

A flame bait: I think that anyone claiming that hand coded assembly is faster or smaller than fully optimized high-level complied code is either
-talking about a few isolated lines in a very specific situation
-doesn't have a very good idea about how good a good compiler really is
-is using crappy tools
-or doesn't know how to use the tools.

As my first programming project,  I have written a point of sale software in assembly which consists of two files: the cash register (88.0KB) and the inventory(75.5KB). It is blazingly fast. It is in actual use everyday running off a netbook at our place. In another store, it runs off a desktop.

Though, I agree assembly is mostly useless nowadays. But give assembly its respect.

Good one. Are you still employed?

[kt315]

foo.c and bar.c will be compiled separately. Each .c includes the .h twice, but gets exactly one definition of my_function() because of the include guard. Thus, each .o file will also have object code for my_function().

When you link the .o files into the same executable, the linker will complain that my_function() has multiple definitions. However, if you add 'inline' to the definition in header.h, the inline property carries through to the object code and the linker will simply pick one definition and ignore the others.

For C++, the inline behavior is implicit in member functions defined within the class declaration. That's how you can include gazillions of function definitions from STL header files without getting linker errors.

Define my_function as static and you'll be fine. Static functions have compilation unit visibility.

[westfw]

[quote ]I wish all the best to anyone implementing TCP/IP protocol in assembly [/quote]
http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_1_19910112/01/6-1-monitor/tcptcp.mac.html
(I am the "BILLW" mentioned in the edit history.  (I didn't actually do as much work as might be implied; this is essentially a "local" copy of the code, so the local edits are not as compressed.)
Note the use of local stack variables and data structure definitions.

You can surely define assembly to be "mostly" "useless", for suitable definitions of "mostly" and "useful."  A less contentious statement would be along the lines of "assembly language is seldom required", which I think I'd agree with.  Especially now that CPUs are no longer designed with "clever" assembly language programmers in mind (an 8051 assembly programmer can do a lot of neat tricks that are mostly outside the scope of a C compiler.  An ARM CM0; not so much.)

I'll note that the assembly TCP code linked above is highly obsolete; it only runs in museums and on simulators, the CPU architecture is dead, and the company that sold it is dead; while the 4.x BSD code (written in C) from approximately the same time frame went on to be the grandfather of most of the modern networking implementations that are still running.

[lapm]

Ok, i read throw all 7 pages in this thread, here is my 2 cent...

To me a assembly is just a tool, Now tool needs proper job to be effective. You don't use jackhammer to nail in small nails do you?

There is cases for everything. You might need assembly to get the edge on some jobs, sometimes you don't. If your one of those people that can get by just using high level languages, be glad. Sometimes you just need little extra option.

I started my programming as hobby in 80´s when 8 bit CPU was the thing. Learned assembly on 6502 CPU. Still remember most of op-codes for that out of my head... For general programming i try do high-level languages, they do bring faster development. But sometimes they are not just enough. Depends what your doing.

You might not need specific tool today, but you don't know what tomorrow will throw at you.

If you don't have use for assembly, none will force yo to learn it. Some of us learned it for fun, some because job required at time...

[Rick Law]

The best computer language to use depends on what you're doing - that is why there are so many of them (languages).
...
It is odd, but computer languages like operating systems seems to inspire people with almost religious zeal.

In my view, it is human nature.  Things that takes a lot of effort and energy to master become a great investment.  With great investment comes a protective sentiment to protect the time and energy you have invested.  Who would like to think of themselves as fools having spend years of their life learning something useless or of little value.  Conversely, simple to learn stuff requires merely little investment or none will earned small or no loyalty.  You wont found as much energetic defender of say which font when printed is nicer to look at while we all have our preferences.

Rick 

[blewisjr]

Wow this thread is still going on very interesting.  I like to look at assembler as a choice.  Sure you can use it and it is very beneficial to knowing it for your particular chip as it gives a deeper understanding.  Now the matter of actually developing with it comes down to personal choice or company choice (if it is a company project).  On most modern chips it is probably needed much less then the old chips but even with more modern chips sometimes I am finding it easier to express what I want to do in assembler compared to C.  I am by no means an AVR assembly guru but I do have 10 years experience using C on the PC and even then there are times I feel it is easier to express myself in ASM.  Not sure why maybe ASM just maps to my brain better then C has over all these years.

So overall I feel the only real logical answer to this thread is NO! Assembler is not mostly useless it is a choice just like every other tool used in development.  IE.  Do I have to use git? Is svn mostly useless?  Is vim mostly useless?  No matter where you go you see it and the same answer is always the right one NO they are just a choice and they all can get the job done.

[nctnico]

The problem is that some choices can become a prison...
Many years ago I attended a conference call because my employer wanted to purchase licenses for DSP algorithms. We where talking to a company who was selling DSP modules. When we asked whether the code was portable the answer was no. They coded everything in assembler and they already had a problem because the Motorola DSPs they used where about to be obsoleted and they had to port a huge amount of code to a new (but slightly) different DSP from Motorola. At that time Motorola already wasn't a major player in the DSP field. Analog Devices and TI had conquered that market. So in the end the choice for assembly language put that company years behind the competition. Even today they still use the antiquated Motorola DSPs on their products.

I agree with Rick Law's view on this. People tend to defend their choices instead of wondering they may be wrong. On some fora you get banned if you dare to say PIC stands for 'Pic Is Crap'.

[blewisjr]

You make a good point portability is not a strong hand for assembler and in that case it could put a company out of business.  Instead they could have used C and optimized for various chips using assembler modules which are conditionally used depending on the chip being used if they needed that low level performance.  It always comes down to the right tool for the job and these decisions need to be made on a per circumstance basis.  They did not take into account all the various factors their projects would be dealing with.  Any decision can come back and bite you at some point or another.

[ptricks]

One thing about ASM is if you really understand it well you can pull off some amazing things with little resources. This is a pc OS written completely in ASM and is under 1.44MB.  Sure we don't have to worry about such low resources now, but as a proof of concept it is cool.

http://www.menuetos.net/