Anyone else think assembly is (mostly) useless? - Page 1
Forum section: electronics / general

author: jmole
author_rank: Regular Contributor
timestamp: April 30, 2013, 01:53:34 am
content: So, while I think it's very beneficial toknowassembly, I have never found a place where it was necessary touseassembly in a real design. i.e., most bottlenecks that you'll find in an embedded system have more to do with the architecture design and technology choices rather than that one damn piece of C code that won't run fast enough.Edit: I made a quick video on this topic. Not, by any means, a thorough comparison of assembly and C code, but it shows that while knowledge of assembly is very useful, often the compiler will do a good enough job (with well written code) that you don't need to use it.

author: Rerouter
author_rank: Super Contributor
timestamp: April 30, 2013, 02:13:31 am
content: knowing assembly is mainly about being able to either speed up or shrink down a piece of code better than a compiler can do, though this generally follows the tradeoff of removing easy portability,

author: c4757p
author_rank: Super Contributor
timestamp: April 30, 2013, 02:14:00 am
content: Quote from: wilfred on April 30, 2013, 02:11:41 amThis. Assembly is useless in the same way that a toilet plunger is useless - you don't use it often (at least, hopefully...), butdamndoes it come in handy when you do need it.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: April 30, 2013, 02:16:03 am
content: I would take it you have never coded interrupt handlers in systems where interrupt latency and jitter matter. Every cycle counts in many of the projects I have worked on. Also have had to diagnose and correct object code generated by buggy compilers.Have I just taken the bait of troll?

author: BravoV
author_rank: Super Contributor
timestamp: April 30, 2013, 02:19:27 am
content: Quote from: wilfred on April 30, 2013, 02:11:41 amWhat "if" its not your call to decide which chip to use, say budget constraint or the boss said that you must use cheap underpowered chip ? Thats the reality and what true pros do for living.Rarely used nowadays, mostly perceived by noob as useless but still well respected by experienced users, once needed, you just can't live without it.

author: ecat
author_rank: Frequent Contributor
timestamp: April 30, 2013, 02:42:48 am
content: A basic knowledge of architecture and assembly language is a very useful thing to have and a whole lot of that knowledge is transferable between processors so it keeps on giving.To all the reasons mentioned above I'll add analysing compiler output for common operations and constructs helps with writing efficient code while imposing minimum inconvenience.

author: helloworld922
author_rank: Regular Contributor
timestamp: April 30, 2013, 03:35:48 am
content: Quote from: c4757p on April 30, 2013, 02:14:00 amNice analogy, and I agree with thisEven if you don't end up writing assembly code, I sometimes use dis-assemblers to take a closer look at critical sections of code generated by the compiler (I even do this occasionally on PC programs!). This can help me determine if there isn't a better way to write my C code, or if the best choice is to use assembly code. These are extreme cases where I want as much performance as I can possibly get out of my hardware as possible.So, yes I don't use assembly much, but when just using C code isn't possible, I would rather read/write assembly code over having to read/write machine code any day.

author: digsys
author_rank: Unknown
timestamp: April 30, 2013, 03:51:41 am
content: I've been writing in Assembly for 40+ yrs, and never get tired of it. Yes, I've tried just about every other language out there (usually tofit in with some system I'm adapting to), but never could put up with all their limitations / idiosyncrasies. Yes, you can mix and match,but what a mess that can end up in, especially when a few programmers are involved. I'm fine with it.The VERY OLD argument ... "well just use a bigger chip" has been going on since I STARTED and never seems to go away.It starts with .. use a slightly bigger chip / more IO / RAM ---> then .. use a DIFFERENT chip that has more MIPS and more HLLsupport ---> then ... Lets use an embedded PC / Linux and write it in a higher level than C ---> then .... lets use a Full blown PC,write it in VB / VB Net .. Java .. Flash .. yadda yadda ..... and suddenly a simple solution turns into a ridiculous mess.I couldn't even count how many times I've been caught up in this scenario. THEN we have the repeated rumour how 8-bit is dead !There's NO need ever for 8 bits, as 16/32 is as cheap. After all these years, I sure don't see 8 bit offerings disappearing.Use whatever the FOOK you're happy with, and please try NOT to fuel these Nerd bitch wars that never seem to end.

author: ptricks
author_rank: Frequent Contributor
timestamp: April 30, 2013, 04:00:23 am
content: For MCU you really should know assembly and should be able to understand what is going on internally on the chip, you can still program in other languages. Anyone who doesn't think assembly is relevant hasn't read any data sheets for MCU.

author: marshallh
author_rank: Unknown
timestamp: April 30, 2013, 04:58:43 am
content: No

author: Bored@Work
author_rank: Super Contributor
timestamp: April 30, 2013, 05:08:14 am
content: Quote from: jmole on April 30, 2013, 01:53:34 amThe answer is no, and you are just a stupid troll.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 30, 2013, 05:13:04 am
content: Quote from: Bored@Work on April 30, 2013, 05:08:14 amPot, meet kettle.

author: BravoV
author_rank: Super Contributor
timestamp: April 30, 2013, 05:25:31 am
content: Quote from: jmole on April 30, 2013, 01:53:34 amIs there any chance even though very-very unlikely that the op never heard or understood the word called "bloatware" ?Yeah, I'm pretty sure thats it.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 30, 2013, 06:00:58 am
content: C'mon folks, of course assembler is "mostly useless." No question.Of all the gazillions of lines of code that have been written (by humans), how many are assembler? It's a tiny fraction of the total.If you're hauling out the assembler to speed up some piece of code that's too slow in C, you're only going to beat a (decent) compiler in very specific situations. Your super-efficient assembly code probably has bugs (that you don't even realize) due to simplifying assumptions you've made. Before you get down to writing machine code, you should learn how to make C fast. Do you understand what pointer aliasing is? When should code be inlined? What about 'const' and 'volatile', ever used 'em?Of course, if you're working with some craptastic architecture and a weak sauce compiler, you may be able to do a better job by hand.

author: AlfBaz
author_rank: Super Contributor
timestamp: April 30, 2013, 07:31:04 am
content: Quote from: andyturk on April 30, 2013, 06:00:58 am...and how do you do that if you don't understand the underlying architecture and are well versed in asm?

author: peter.mitchell
author_rank: Super Contributor
timestamp: April 30, 2013, 07:58:21 am
content: Bah, why would anyone want assembly when you can just lean the individual instruction sets and write everything in machine code.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 30, 2013, 08:20:45 am
content: Having grown up on 6502 and later ARM code on BBC/Acorn platforms, followed by a lot of PIC work, it took me many years to accept that C compilers were worthwhile, but nowadays I'd totally agree that it is rarely necessary to be able to write assembler these days, but it is very important to have enough understanding to be able to read it, so you can check what a compiler is generating, both for problem solving, debugging and analysing where efficiency can be improved.Understanding assembly and the low-level hardware is the key to writing efficient code, especially with non-optimised compilers like GCC.Once you know one or two instruction sets, minimal learning is needed to get enough understanding of a new architecture to follow code and get a feel for efficiency. The level of detail needed to write new assembler code is rarely necessary.The only exception would be the very lowest end chips, and even there, it's only really essential for high volumes where you need to minimise cost by using the smallest possible chip (in terms of memory or peripherals) - for lower volumes the additional cost of a bigger chip is a lower cost than the additional development cost.

author: Corporate666
author_rank: Unknown
timestamp: April 30, 2013, 08:27:05 am
content: I think many engineers fall victim to wanting technical perfection without regards to time or cost, or the realities of business. Not all, but many. I've worked with engineers who will only use assembly because it's faster and more compact, and will happily spend much more time developing and debugging a program where the run speed or memory footprint were not important.From that standpoint, C is very useful because you can much more quickly develop a project.Having said that, I started off with x86 assembler about 20 or 25 years back, and while I grew to love it, I then grew to hate having to use it. But it has a place... whether it's control over memory locations or execution speed or code compactness, there are times when nothing but assembler will do.So no, I do not think it is mostly useless... but I do think that it's role has greatly diminished over the last decade or so, and it is sometimes overused needlessly.

author: AlfBaz
author_rank: Super Contributor
timestamp: April 30, 2013, 08:44:58 am
content: Quote from: mikeselectricstuff on April 30, 2013, 08:20:45 amHaving said what wrote earlier I have seen this very knowledgeable fellow over at microchip forum's (john temples) that has said that even for simple devices you can get good clean assembly out of C for very low end devices.IIRC he had created some simple code in C that took in a serial stream and sent it out at a different rate and the assembly was as good as it gets.However he knows all the C standards inside out and as such is aware of compiler limitations He also has a very good understanding of assembly.I don't know that your average C coder without assembly knowledge and probably more importantly what the various tools in the compilation chain do to your source could have written code that efficientlyEdit: the low end mcu had no serial peripheral

author: jpb
author_rank: Super Contributor
timestamp: April 30, 2013, 08:47:02 am
content: As a young engineer I remember going to a presentation by a large French organisation that were selling a simulation system that could work with anything that could be described by differential equations (e.g. electronic circuits as well as physical systems). It was a very big, and very expensive piece of software but what I remember most was it was all written in VAX assembler! Now the VAX is no more presumably that monumental human effort is now defunct.c was invented to replace assembler in writing OSs in particular so it is very close to assembler (with all the bit manipulation and the ease in which you can store different types in the same memory space) so for most systems it makes sense to write the bulk of them in a high level language like c.But assembler is not useless, you actually know what is happening with assembler as well as it being faster, for example in one project I was doing I was using a bit field in c to store flags. One of my values was 2 bits and it was unsigned so I wanted to store the numbers 0,1,2 or 3. I found that when I put a 3 in (and I had declared it to be unsigned) it still failed the test for equality with 3. The reason was it was treating the binary 11 as 2s compliment and expanding it up to be -1 when doing the test.Personally on something like an embedded system I'd have thought that the I/O and very time dependant stuff might best be done in assembler while things like FFTs are probably best programmed in c.

author: Kremmen
author_rank: Super Contributor
timestamp: April 30, 2013, 09:25:57 am
content: While fully aware that this is a never ending story, allow me to deposit my 2 cents.A personal level observation is that as in any endeavour, also in SW engineering there are fundamentally different kinds of people involved. Experience of course is one thing and it may explain some of the opinions (it is exciting to some to be able to control every aspect of a processor on the minutest detail level. It also usually gets old after a while). But that aside, the Gaussian curve rules. At one end are the control freaks who simply must know everything or the world collapses. The opposing end is populated by the laissez-faire posse who coudn't give a s**t what happens inside, only that their software runs as specified on the high level. The rest of us find our places somewhere in the middle.What i am trying to say is that use or otherwise, of assembly is not primarily a technical issue, but an attitude. At least where the ends of the bell curve are concerned. Yes there are valid (technical) reasons for using assembly, but less than the most diehard advocates let us understand. The majority of "standard" cases where assembly would be needed tend to be included in architecture specific constructs embedded in this or that library or header. So while technically expressed in assembly, in practice a part of the toolchain environment. In my book that does not count as programming in assembler any more than printing the compiler generated assembly does.I have started programming embedded systems when Intel 8080 and heaven forbid, 8008 were newish or at least relevant chips and PL/M was supposed to be a "high-level" language. Ever since, i have needed assembly in implementing the few kernel functions in RTOS:es where you just have to manipulate the stack directly. Even that could conceivably be done in C but not without calisthenics making assembly the easier choice. Other than that the only items that come to mind are interfacing an ancient AMD 9511 coprocessor and even that would have been doable in PL/M (or C for that matter).As so many have noted already there is a valid reason for using assembler to solve a specific requirement for program speed or size. At the same time i have seen numerous cases where the most cunning assembly algorithm was ultimately futile because optimization will only get you so far and in the end you have to look for fundamentally different solutions. Of course there are special cases where a hand crafted algorithm can speed a loop an order of magnitude or more and then assembly is warranted. It just seems that such cases are getting increasingly rare.As to the claim that knowing assembler is good because you can then verify that the compiler is doing its job - i disagree. Sure, one can possibly learn the architecture of a specific chip well enough to be able to do that but then that knowledge is associated with that particular chip. Change architectures and the knowledge is, if not worthless at least worth significantly less. In my opinion this argument is fundamentally flawed because nobody a) checks a large application like this anyway, b) trying to guess which parts to spot check - you will eventually guess wrong and c) if it really is important, there are numerous profiling tools made expressly for this purpose. Those make short work of finding out where the execution flow spends its time. Regarding a) and b), who actually cares how the generated assembly looks like if it does the job correctly and is fast enough? Also, try to follow on the assembly level C/C++ code optimized to the max and i promise you'll sprain your brain.Having said all this, i also want to say that i am not a die hard opponent of assembly. Just that many if not most of the pro arguments i hear are the flawed ones that i rant against above. All the real arguments are mostly against using assembly: maintainability, productivity, portability, testability.Maybe i am just too lazy or too far in the bell curve to care but my projects seem to do quite well without a line of assy involved. YMMV.

author: JuKu
author_rank: Frequent Contributor
timestamp: April 30, 2013, 09:26:55 am
content: No, it is not useless. You really need it:- To learn how microcontrollers (and real computers, but to lesser extent) really work and what they really are doing- To learn why you don't want to use it, unless you really have to- To write compilers and OS kernels- When you need sub-microsecond jitter or response time in few microseconds in your interrupts (but more often than not, you are doing it wrong)- When it makes economical sense to use a chip that is 10c cheaper and the application is very simple (but you still might be doing it wrong, although not as often as in the previous case)- You are forced to update a very old system (but then, you are doing it wrong) or one that was done wrong to begin with- In a hobbyist cases, when you can't afford to do it rightAnd yes, it is mostly useless in real world, where productivity and reliability counts.[ I build real time embedded systems for living. As a rough estimate, I would say that the ratio assembler vs high level language is 1 to 100000. But I don't write OS kernels, I just use them. At design time, the estimated quantities are in thousands (not in hundreds of thousands, that would change the equation!). So, a chip costing 1€ more is ok, if it saves a month in engineering. And a month is not much at all amortized over design, development, testing and maintenance. And 1-2€ buys a lot today: That's a difference of a tiny 4 or 8 bit micro and powerful 32 bit. It also pays for a dedicated peripheral controller or FPGA. YMMV, but assembler is hardly used in real life, in my work, practically never.When I hire microcontroller engineers, I would not hire somebody who doesn't know assembler, nor would I hire somebody who prefers to use assembler. ]

author: blewisjr
author_rank: Frequent Contributor
timestamp: April 30, 2013, 10:03:29 am
content: I found this discussion rather interesting so I felt I would chime in. First and foremost I agree that the uses of assembler in modern times is relatively moot considering how smart C compilers have become. Outside of a few small cases like others have stated you can save yourself tons of time and bugs using C. But despite all this I have been using assembler. I am new to micro controllers in general and even new to assembler. I have programmed in C for nearly 20 years now but I am using assembler on my AVR's and PIC's. Why you ask? It is quite simple personal preference. 1. I have always wanted to learn assembler. 2. I always like to learn something new if I am not learning it is not worth doing. 3. I enjoy assembler, no crazy convoluted abstractions just up and straight do this. 4. I enjoy the challenge in trying to figure out how to do something that could be just 3 lines of code in C. It is a new thought process and over all it is making me a much better developer even from the C side.So over all I think it is worth learning and using assembler at least until the buzz wears off the knowledge gained is valuable.

author: amyk
author_rank: Super Contributor
timestamp: April 30, 2013, 10:50:29 am
content: No, Asm is not useless although it might not be the default go-to for most tasks now. Not only optimising, but when debugging, it's important to be able to figure out what the compiler's generated and wht it's doing. The strength of HLLs lies in their conciseness and ability to generate large amounts of code quickly; quality-quantity tradeoff. At the same time the abstraction can limit what the programmer wants to express and optimise, because the compiler mostly has to follow the language standard and doesn't know of the assumptions the programmer had in mind.

author: nuhamind2
author_rank: Regular Contributor
timestamp: April 30, 2013, 11:35:12 am
content: What about peripheral. Microcontroller is not just about the core right. Like Timer, what if I set this register like this, what if I set that register like that ,what If I want to divide clock by some value, what if I want to compare match happen at some value. Aren't we actually studying the 'assembly' of that peripheral

author: AlfBaz
author_rank: Super Contributor
timestamp: April 30, 2013, 11:44:10 am
content: Quote from: nuhamind2 on April 30, 2013, 11:35:12 amNo. What we are studying is the peripherals register set and their addresses are usually defined in the MCU's include file. I often find it quicker and easier to read the data sheet and understand the registers than trying to decrypt the mcu vendor's library functions

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 30, 2013, 11:48:30 am
content: Quote from: AlfBaz on April 30, 2013, 08:44:58 amYes, but at this level you need to regard the C compiler as little more than a macro-assembler and keep a tight eye on the output.The differences between C and assembly become less significant at this level, and sometimes assembly has some advantages in terms of things like optimising register usage on register-rich architectures like AVR and ARM, and making full use of status bits etc.A good example of the 'macro assembler' approach is using carry bits after a shift operation, which C does not support very efficiently. e.g.on the PIC :reg<<=1;if (CARRY) .....; // use hardware carry flag because you know what the compiler did with the previous instruction

author: nuhamind2
author_rank: Regular Contributor
timestamp: April 30, 2013, 11:56:56 am
content: Quote from: AlfBaz on April 30, 2013, 11:44:10 amWhat I mean is we still need to learn low level aspect of microcontroller.Quote from: AlfBaz on April 30, 2013, 11:44:10 amI agree

author: jpb
author_rank: Super Contributor
timestamp: April 30, 2013, 12:39:17 pm
content: It is going a little off topic, but when I first learnt c it was closer to being like assembler. In particular there was the register type which you could use to tell the compiler which integers you wanted stored in registers instead of on the stack. But compilers now just ignore such directives as they know better how to do optimising of registers.I used to like the BBC Micro Basic approach of having an in-line assembler.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 30, 2013, 03:14:46 pm
content: Quote from: jpb on April 30, 2013, 12:39:17 pmIt can't always know what you want - for example you may want to dedicate some registers for use by an interrupt task to reduce context save/restore time. The IAR compiler allows this by specifying variables to be in a specific register - not sure if it pays attention to the register qualifierQuoteAbsolutely - it was the ultimate macro-assembler!

author: jpb
author_rank: Super Contributor
timestamp: April 30, 2013, 03:19:20 pm
content: to quote from Real Programmers Don't Use PASCAL,"If you can't do it in FORTRAN, do it in assembly language. If you can't do it in assembly language, it isn't worth doing."http://www.ee.ryerson.ca/~elf/hack/realmen.html

author: Rufus
author_rank: Super Contributor
timestamp: April 30, 2013, 03:25:09 pm
content: Quote from: Bored@Work on April 30, 2013, 05:08:14 am+1 on the troll bit, can we have a thread about verilog vs. VHDL, about C vs. C++, about Microchip vs. Atmel?

author: croberts
author_rank: Regular Contributor
timestamp: April 30, 2013, 03:38:02 pm
content: All designs are contextual. If assembly language was useless (to me) the network and control system for my whole house solar powered LED lighting system would not be functioning. Designers should use whatever programming language they feel is appropriate for the project they are doing and perhaps equally important that they feel comfortable and confident using.

author: kfitch42
author_rank: Frequent Contributor
timestamp: April 30, 2013, 03:39:08 pm
content: To summarize the discussion so far:1) It is always important to understand the layer below you. If writing C, understand (but not necessarily use) assembly. If using assembly understand CPU/system architectures... ( on a related note you should also understand the layer above...)2) When push comes to shove, hand optimization of assembly is sometimes necessary (for throughput/latency/size...).3) Compilers/kernels/BSPs(board support packages) don't materialize out of thin air. Someone somewhere wrote some assembly (possibly gcc inline assembly) to initialize the chip in the right mode. And someone else wrote the code that takes your C and turns it into assembly. Sure hope that guy knew assembly

author: AlfBaz
author_rank: Super Contributor
timestamp: April 30, 2013, 04:26:15 pm
content: Quote from: kfitch42 on April 30, 2013, 03:39:08 pm+1I can't think of many engineering disciplines that don't require you to know the fundamentals, you may not need them but you should still know them.Sometimes if you are doing tricky shit the only way to access some of the core stuff is with inline assembly, namely because that core stuff is used by the compiler and it wont give you access to it. In this case not only do you need to know asm you also need to know the compiler and the subsystem it creates to manage and run your code.

author: nctnico
author_rank: Super Contributor
timestamp: April 30, 2013, 07:22:43 pm
content: Quote from: kfitch42 on April 30, 2013, 03:39:08 pmThese are only valid if you need to interact with low level CPU stuff. Lots of software doesn't need that. In fact most software engineers have no clue about what is going on exactly but are still very capable of delivering a good piece of software. Being able to write better assembly than a C compiler is a myth unless the compiler is extremely crappy. Most compilers are made by very competent people who know how to get the best performance or code size. The last time I used inline assembly (one line) was to get the stack pointer in a fault handler for a Cortex Mx microcontroller. That is the only assembly you may need on a Cortex Mx controller. They can start a C program without needing any assembly to setup a stack pointer etc.

author: c4757p
author_rank: Super Contributor
timestamp: April 30, 2013, 07:32:04 pm
content: Quote from: nctnico on April 30, 2013, 07:22:43 pmFrom a practical point of view, you are absolutely correct. Still, a programmer who doesn't know what a stack pointer is is just sad. Maybe it doesn't say anything about their ability to deliver correct software, but it sure as hell speaks volumes about their interest in the subject, and I'd worry about the quality of something designed by an engineer who's not interested in what he does.Personally I think that being of the mindset required to actually try to avoid learning something is indicative of a severe lack of passion.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 30, 2013, 07:52:49 pm
content: Quote from: nctnico on April 30, 2013, 07:22:43 pmInline assembler is pretty handy when you need it. Of course, you have to understand what the compiler is going to do with the few lines of assembler. GCC has some pretty neat stuff for specifying where the assembler operands come from.One thing that rubs me the wrong way in the mcu world is OEMs who ship code in assembler when it could easily be in C. Initialization of static variables (i.e., the code that runs before main()) is a classic example. This is easily done in C, and much more understandable that way compared to its assembly equivalent.

author: c4757p
author_rank: Super Contributor
timestamp: April 30, 2013, 07:55:56 pm
content: Quote from: andyturk on April 30, 2013, 07:52:49 pmReading it is a good way to get a feel for the optimal way to write that sort of stuff in assembly for that specific MCU. Assembly can definitely be a "write-only" language, but in my experience the example code is usually written well enough that you can read it easily.

author: nctnico
author_rank: Super Contributor
timestamp: April 30, 2013, 08:23:00 pm
content: Quote from: c4757p on April 30, 2013, 07:32:04 pmI strongly disagree. Its all about focussing on what is relevant and what is not. In C and C++ you have to worry about pointers and dynamic allocation. In languages like PHP, Java and Lua you don't have to worry about those. This means you can spend more energy on creating great new software instead of being held back by having to deal with the low level stuff. Taking technology for granted and using existing technology as bricks (black boxes) to create new software is the way technology moves forward.

author: marmad
author_rank: Super Contributor
timestamp: April 30, 2013, 08:41:33 pm
content: Quote from: nctnico on April 30, 2013, 08:23:00 pmSometimes technology moves forward because someone steps backwards and takes apart one of the black boxes - and then recreates it in a much more efficient, innovative, or easy to use way. If you think progress only comes from using tools which someone else - with their own set of misconceptions and vertical thinking - developed, you're badly mistaken.

author: jpb
author_rank: Super Contributor
timestamp: April 30, 2013, 09:02:20 pm
content: The best computer language to use depends on what you're doing - that is why there are so many of them (languages).I program in SML (a functional programming language) and in C most of the time. SML is statically typed and is very good for anything involving pattern matching. It is very robust which arises from its origins in Logic and Theorem Proving. But when it comes to code that interfaces more directly with hardware it obviously makes more sense to use a language such as C or assembler even.Sometimes you want to write code that is independent of hardware and sometimes you want to do the opposite, most programmers/engineers should have the interest to find out about both approaches. Most of the time I don't want to know if integers are stored big-endian or little-endian for example but it might be dangerous not to even know that there are differences between various processors.It is odd, but computer languages like operating systems seems to inspire people with almost religious zeal.

author: jmole
author_rank: Regular Contributor
timestamp: April 30, 2013, 09:07:10 pm
content: My point is, writing some assembly is not necessarily the answer to speeding up your slow-ass program. You need to have a good knowledge of the system you're working with, the execution pipeline, and the alternative solutions, before you can make an informed decision on whether or not you really need to use asm to speed up some time-critical loop (or ISR, or whatever).

author: ben_r_
author_rank: Frequent Contributor
timestamp: April 30, 2013, 10:27:03 pm
content: Huh, thats funny, I personally ONLY use assembly when working with MCUs (PICs). I actually do not like higher level languages for them and prefer to have complete control and understanding of whats being done. But I know for many learning assembly is like how most people feel about learning math. For me it was just made more sense and thus came easy.

author: c4757p
author_rank: Super Contributor
timestamp: April 30, 2013, 10:39:41 pm
content: Yeah, I've never thought of assembly as difficult or tedious for low-level "microcontroller-y" tasks. I wouldn't try to write a word processor in it, but it's always seemed to be about an equal choice for microcontroller stuff. Really, most of the functions you call and statements you write end up being just a shove or two into a register on a microcontroller.

author: free_electron
author_rank: Super Contributor
timestamp: May 01, 2013, 12:11:31 am
content: Quote from: andyturk on April 30, 2013, 06:00:58 amthat may be, but realise this : anytime the computer starts , it is a chunk of assembly that finds and initializes all peripherals , goes to seek the bootsector , loads the assembly program that is stored there and then loads to Os.Without assembly your machine would not boot...C is handy dandy except if you have a freshly reset cpu where the memory controller is not initialized so you have no stack , no ram no nothing and you need to bring it up .... good luck doing it in 'c' ... ( there are bioses that are mainly written in 'c' but the real startup code, the first few hundred bytes of code the set the machine in the right mode are handwritten assembly.so don't dis it...Besides speed and size there are other situation. situations so critical you simply don't trust a compiler ! just moving a block of code may cause the compiler to create completely different code . simply because it now walks a different optimizer pathway.sometimes compilers are bloody annoying like when they 'optimize' a block of code away because it is never called... or that's what it thinks... what if there are instance where the cptr and dptr are manipulated outside the scope to call that function directly.in that case you write some stuff as inline assembler and tell the compiler : hands off.other cases are where a new core is available but the compiler has no support for a specific feature yet.... like a core that all of a asudden has extra interrupt vectors. at least then you can throw in an 'org xxx' to offset code generation and write some hooks in assembly to patch in the unsupported stuff until the compiler builders can catch up.an extreme case is to provide patching code... a chunk of silicon has a hardware bug. at boot a chunk of assembly is called that circumvents the normal startup , patches the core and then the compiler can go off.. i know several cpu's ( Arm7 based) that have such problems. the assembly code sets the registers right so a normal program can run

author: croberts
author_rank: Regular Contributor
timestamp: May 01, 2013, 12:28:39 am
content: Assembly language is just that...a programming language. This is not the first time I have observed a topic disparaging it. Assembly language is no threat to the favorite flavor of high level language so a more interesting question is why an attempt to declare it "useless" by consensus? To paraphrase the line from Shakespeare's Hamlet "The forum doth protest too much, methinks."

author: kt315
author_rank: Regular Contributor
timestamp: May 01, 2013, 02:40:25 am
content: If you can avoid using assembler you should by all means do it. There are case when you cannot, but it happens way less often than some of the comments above may imply.People have not come up with a better way to deal with complexity so far other than raising the level of abstraction. We program FPGA in verilog and VHDL and do not worry too much if the compiler is not going to use efficiently every single logic gate. We sure could draw a hardware like schematic for every FPGA system, could not we?While we are talking about a hobby, your time is essentially free (you are not working -- you are having fun, at least that is the idea).I wish all the best to anyone implementing TCP/IP protocol in assembly (if you are up for the challenge, shoot for a web server).Modern embedded systems has millions of lines of code (android is a great example), and even programming chips like pic32 would be way too expensive in assembly language alone.It is not about assembly vs C, it is about picking up the right tool for the job. And if the only tool you have is a hammer -- all the problems look like nails.You will move way faster if you can use a higher level language, until you run into hardware limitations that is; and even then, you might need just a tiny bit of assembly, which should be in a separate module anyway.If the only language you recognize is assembly -- try learning C, you will find a lot of way more efficient ways (implementation time wise) doing things.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 01, 2013, 04:53:46 am
content: Quote from: free_electron on May 01, 2013, 12:11:31 amARM Cortex-M3 will boot just fine without assembly. The first word of your reset vector is the stack pointer, and the second is the reset handler. They're just addresses--no opcodes involved, and hence, "no assembly required."

author: Psi
author_rank: Super Contributor
timestamp: May 01, 2013, 05:01:52 am
content: Micrcontroller assembly is for when management refuse to do the project properly and want a cheap 'patch job' instead.- More code needed in an already full micro.- More speed from existing micro instead of using a newer/faster one.- Substandard micro selected for the job due to price.For more advanced stuff, like PC's or phones, where you have 3rd party apps, assembler is useful to get an edge over your compeditors by having a faster app on the same hardware.- Faster framerates in PC games- Quicker image manipulation routines

author: AlfBaz
author_rank: Super Contributor
timestamp: May 01, 2013, 05:56:07 am
content: Please raise your hand if you think assembly is useless and you know nothing about it

author: amspire
author_rank: Super Contributor
timestamp: May 01, 2013, 06:03:44 am
content: Quote from: Psi on May 01, 2013, 05:01:52 amI find this totally weird.It is good engineering to get the maximum performance out of a part. If you can save 20c on a micro by using assembler, that is good design. C is good. Assembler is good. Well written assembler is better then badly written C.I have done a number of micro jobs where the performance depends totally on a small interrupt routine that has to be optimized for clock cycles. Using assembler can reduce the clock cycles sometimes by 10%, but sometimes by over 50% and that is huge. It means by using assembler, you can often double the speed of your hardware if the interrupt is the bottleneck.If a micro can do the job if assembler code is used, how can it be a "substandard" micro? That is like calling a LM324 a "substandard opamp" just because there are better ones that cost several times more.I think what you are referring to is substandard engineering where the solution is to spend more money on components to compensate for the lack of design skills.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: May 01, 2013, 06:44:25 am
content: Quote from: amspire on May 01, 2013, 06:03:44 amI have only limited ASM exp. from only getting other's code to work on a desktop. But can't you inject ASM into C?The only micro I program is arduinos from that awful IDE for small hobby projects, but I would have thought for serious micros, you'd write everything in C for cross platform swap-ability on micros and drill down on the bottlenecks.That's how I was taught. Don't waste time on optimising for bottlenecks you envisage because the real ones you don't think about are the ones that get you.I only speak a little of x86, can any of you tell me how much difference in dialect the new micros are with each other and also with ARM?I want to know if you can build a collection of your own routines in ASM like you do in C, but I wonder how you'd switch to different CPUs.Or is the normal use of ASM in microcontrollers just moving regs to/from input/output pins?

author: caroper
author_rank: Regular Contributor
timestamp: May 01, 2013, 07:19:57 am
content: I confess I have not read the whole thread so I will not comment on the relative merits of C vs Assembler, I am sure there are many excellent post on that already. What I would like to do I point out that Assembler is certainly not redundant, in fact it is critical to the C programmer.The C compiler is really just an Assembly Language pre-processor, in the same way that C++ is a C language pre-processor.The C compiler produces Assembly language out put which the linker combines with Object Files (also assembler even if generated in C) to assemble the final code.Saying that Assembler is useless because you use C is the same as saying your car needs no Gearbox because you have automatic transmission.The need to lean Assembly language may not be as great as it once was, in the same way that you don't have to learn to use a manual gear shift and clutch, but is Assembly Language Redundant? not until CPU architectures change dramatically, no.CheersChris

author: BravoV
author_rank: Super Contributor
timestamp: May 01, 2013, 07:22:45 am
content: Quote from: jmole on April 30, 2013, 01:53:34 amI'm really surprised that you updated your 1st post with that new video as an example to emphasize what are you trying to say after all replies you've received here.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 01, 2013, 07:26:57 am
content: Quote from: amspire on May 01, 2013, 06:03:44 amOnly if the volumes are such that the cost saving in production is more than the cost of the additional development time.Engineering is about the whole picture, not one detail.

author: mikes
author_rank: Regular Contributor
timestamp: May 01, 2013, 07:54:46 am
content: Quote from: jmole on April 30, 2013, 01:53:34 amThen you've never worked on a real time system where one needs to count cycles. Or had to fit a new feature into a fixed space (anything a compiler can do, an assembler can do better, but probably with more difficulty).If someone doesn't understand/use assembly, it in no way makes it "useless," any more than prepackaged sliced bread makes flour and knives useless.

author: flynnjs
author_rank: Contributor
timestamp: May 01, 2013, 09:16:06 am
content: My analogy is that assembly is like a scissors and high level language is like shears.You can make a more accurate hair cut with scissors.You can shave your head quicker with shears.Some people want a nice styled haircut, others just want a quick method to rid excess hair.Selecting a language is an engineering choice and good engineers thinkcommercially not just technically (real ones, not just hobbyists).PS: Not trying to pick a %-B with anyone who grows their hair longer

author: jpb
author_rank: Super Contributor
timestamp: May 01, 2013, 09:54:56 am
content: accuracy depends on the scale of the project.I'd say assembler is more like a small pair of scissors that you get on a pocket-knife - good for trimming your eyebrows but larger scissors (higher level language) will do a better job on a complete haircut!In the same way, I'd trust code for something large and complex more if it was written in c than in assembler simply because the volume of assembler code would be a lot more and harder to follow so more chance of human error.

author: amyk
author_rank: Super Contributor
timestamp: May 01, 2013, 10:43:45 am
content: Quote from: kt315 on May 01, 2013, 02:40:25 amOr how abouta whole operating systemcomplete with network support?One thing I've noticed (on non-embedded platforms) is that learning order is significant; those who start with Asm and then work their way up to some HLL like C also tend to write more efficient HLL code, while those who start with a HLL and then have to use a small bit of Asm for whatever reason tend to write it much like a compiler would, i.e. not very well and they have to go back and do even more work to optimise it. Those who say a compiler can easily beat a human in size or speed are probably comparing to the latter, and in that case I'd agree, but the former, starting with knowing how to do things that HLLs can't, will win easily.

author: AlfBaz
author_rank: Super Contributor
timestamp: May 01, 2013, 11:28:09 am
content: It strikes me that many of the comments here are by people who don't really know what it is to do a major project in assembly.Following it would be easier than you think. It would nearly all be written with macros, its not uncommon for a proper assembly programmer to have massive libraries of macros and custom pre-processor directives, you would be amazed at the crafty techniques utilising the compilers' pre-processor.Encapsulation, data hiding, type checking and a lot of the other HLL paradigms have been around since programming began, only you had to implement them yourself. As HLL's progressed, more and more of these OOP principles where added and developed and they became more strict to prevent silly mistakesAs computers became more prevalent, people and businesses started to rely on them more and more it became unacceptable to have a rogue program taking down the whole system. So OS's became more robust and more restrictions placed on what software could and couldn't do. CPU's with privileges and terms such as ring 0 ring 1 etc would prevent user software "hitting the metal".Programming languages have also taken this road but in the embedded world, many times the only thing running is your software and the only underlying "system" is the programming environment. It's effective not only at compile time but also at run time.HLL's seem to offer a far more robust environment but it comes at a cost and you can find yourself writing a lot of code to get around some language restriction to achieve something can be accomplished with a hand full of assembly instructions. In these circumstances, ignore assembly at your own peril.

author: kt315
author_rank: Regular Contributor
timestamp: May 01, 2013, 01:33:57 pm
content: Quote from: amyk on May 01, 2013, 10:43:45 amI never said it is impossible, it is just impractical. You can dothisas well, except there are more efficient ways to do it. There is nothing wrong with that while you are doing it for fun. If you are aiming for results, it is just not the best way to do it.And regarding optimization a compiler can do, I would not discard it so easily. I know I am going to open a new can of worms, but embedded development tools are still at its infancy. It looks exactly as desktop software development looked in 1995: there is a ton of compilers each with it is own idiosyncrasies, and "ANSI C" support is considered to be a major features (as oppose of lack of thereof being considered as a design flaw). "Michrochip releases a graphics library"!!! Yay! We can now draw a line ... again. And we have a bunch of widgets, all of which look like Win 3.11. We still publish API documentation in PDF, and distribute software libraries in source form as windows installers. There are sure other companies out there, but they are not far ahead in terms of software development support ...

author: andyturk
author_rank: Frequent Contributor
timestamp: May 02, 2013, 02:21:48 pm
content: Quote from: jmole on April 30, 2013, 01:53:34 amJust watched a couple of your videos. Nice work!BTW, I don't think the compiler inlined your bit flipping code because the main program didn't "see" the function definition. If you put the definitions in the .h file with the 'inline' keyword, then the compiler has a choice to generate a call or expand it like a macro. The PSoC IDE probably doesn't work that way, so you'd have to jump through a few hoops to actually inline generated functions.Newer versions of GCC (which is probably the compiler used in Cypress' stuff) support Link Time Optimization (LTO) which lets the linker have a crack at inlining small functions. I've never tried it though.

author: jmole
author_rank: Regular Contributor
timestamp: May 02, 2013, 05:48:19 pm
content: Quote from: andyturk on May 02, 2013, 02:21:48 pmThanks!The .h file with the function is eventually included (through some series of files) into main.c. I am wondering if it's because the inline keyword wasn't used in the definition.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 02, 2013, 09:26:54 pm
content: Quote from: jmole on May 02, 2013, 05:48:19 pmIt seems unlikely that the function definition (i.e., the stuff between the {}'s) would be in the .h *without* being declared inline. Doing that usually leads to multiply defined symbols because every file which includes that .h will generate code for the function. The inline keyword not only tells the compiler that it *might* want to expand the function in-line, it also tells the linker not to complain if there are multiple definitions at link time. The main thing to remember is that 'inline' is only a suggestion. The compiler can still emit a function call if it thinks expanding it would be too complicated or incompatible with other compiler options.All of which goes to show that knowledge of assembly/machine language is pretty useful, but writing a lot of it yourself might not be as good as understanding what your compiler is doing to your code.

author: jmole
author_rank: Regular Contributor
timestamp: May 02, 2013, 11:12:21 pm
content: Quote from: andyturk on May 02, 2013, 09:26:54 pmThis is what header guard defines are used for.Quote from: andyturk on May 02, 2013, 09:26:54 pmVery true, and cuts straight to the point of this discussion. You gotta know what your tools are doing to really know if assembly is a worthwhile undertaking.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 03, 2013, 12:04:44 am
content: Quote from: jmole on May 02, 2013, 11:12:21 pmNot really. Consider the following:header.hCode:#ifndef _HEADER_H_#define _HEADER_H_void my_function() {// yada yada}#endif // _HEADER_H_foo.cCode:#include "header.h"#include "header.h"void foo_fn() {// yada yada}bar.cCode:#include "header.h"#include "header.h"void bar_fn() {// yada yada}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.

author: jmole
author_rank: Regular Contributor
timestamp: May 03, 2013, 12:10:12 am
content: Quote from: andyturk on May 03, 2013, 12:04:44 amThat's why you define functions in a .c file, rather than a header. PSoC Creator does this with it's generated source files, as well. The declaration is in whatever.h, the definition is in whatever.c

author: c4757p
author_rank: Super Contributor
timestamp: May 03, 2013, 12:15:51 am
content: Quote from: jmole on May 03, 2013, 12:10:12 amAnyone who puts functions in a header should have his hands cut off.Hyperbole? What hyperbole?

author: andyturk
author_rank: Frequent Contributor
timestamp: May 03, 2013, 01:18:42 am
content: Quote from: jmole on May 03, 2013, 12:10:12 amQuote from: c4757p on May 03, 2013, 12:15:51 amGuys, if you want your compiler to inline for you, it has to see the actual function definitions. Conversely, splitting the definition from the declaration in the typical way *prevents* inlining:silly.hCode:int plus_one(int x);silly.cCode:int plus_one(int x) {return x+1;}main.cCode:#include "silly.h"#include <stdio.h>int main(int argc, char *argv[]) {printf("the value is %d\n", plus_one(10));return 0;}The compiler *has* to emit an actual function call to plus_one() because it can't inline a function it hasn't seen.If you want the compiler to inline, then put the entire definition of the function in the .h file.silly2.hCode:inline int plus_one(int x) {return x+1;}If you're using a C99 compiler, you (somewhat perversely) have to put an extern definition in exactly one .c file to make sure there is an actual non-inline implementation:main2.cCode:#include "silly2.h"extern int plus_one(int x);int main(int argc, char *argv[]) {printf("the value is %d\n", plus_one(10));return 0;}Quote from: jmole on May 03, 2013, 12:10:12 amAnd that's why the GPIO calls in the bit bang example weren't inlined.Generally speaking, inlining in straight C is a pain in the neck because different compilers do it different ways. It's much easier to get the same effect in C++ with inline member functions.

author: c4757p
author_rank: Super Contributor
timestamp: May 03, 2013, 01:29:41 am
content: QuoteTrue. It was an intentionally kneejerk-ish response meant to be a joke, coming from someone with mostly PC programming experience (where inlining functions really isn't a big deal). MCU programming is indeed the Land of Intentionally Broken Rules.

author: c4757p
author_rank: Super Contributor
timestamp: May 03, 2013, 01:33:03 am
content: As a bit of an aside, a long time back I had a pet project (never finished) - a sort of "modernized" C-like programming language and compiler. Itcouldinline across compilation units - both shared libraries and unfinished (not linked yet) object files had a serialized, compressed version of the parse tree for any inline functions, to be quickly grabbed by a compiler and embedded as an inline function into the current compile unit.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 03, 2013, 01:39:00 am
content: Quote from: c4757p on May 03, 2013, 01:33:03 amSeenthis? Looks interesting, but I haven't tried it yet.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).

author: jmole
author_rank: Regular Contributor
timestamp: May 03, 2013, 01:41:48 am
content: Quote from: andyturk on May 03, 2013, 01:18:42 amnice explanation, thanks!

author: c4757p
author_rank: Super Contributor
timestamp: May 03, 2013, 01:42:48 am
content: Quote from: andyturk on May 03, 2013, 01:39:00 amHey! They stole my idea!Actually, no, I haven't seen that. I'm not very familiar with GCC.QuoteYup. 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...

author: andyturk
author_rank: Frequent Contributor
timestamp: May 03, 2013, 02:12:56 am
content: Quote from: c4757p on May 03, 2013, 01:42:48 amLLVM 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...

author: AlfBaz
author_rank: Super Contributor
timestamp: May 03, 2013, 02:35:19 am
content: Quote from: andyturk on May 03, 2013, 02:12:56 amARE YOU SERI... %-BQuoteI go home now

author: JuKu
author_rank: Frequent Contributor
timestamp: May 03, 2013, 05:56:00 am
content: 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.

author: MrPlacid
author_rank: Frequent Contributor
timestamp: May 03, 2013, 07:53:30 am
content: Quote from: JuKu on May 03, 2013, 05:56:00 amAs 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.

author: BravoV
author_rank: Super Contributor
timestamp: May 03, 2013, 08:08:00 am
content: Quote from: MrPlacid on May 03, 2013, 07:53:30 am+1, declaring it is utter useless is just a stupid & ignorance "attitude", and worst keep defending that statement is definitely an attention whore/troll.

author: amyk
author_rank: Super Contributor
timestamp: May 03, 2013, 10:12:40 am
content: Quote from: JuKu on May 03, 2013, 05:56:00 amTo 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 thedemoscene, lots of examples ofextremesize optimisation there.

author: jpb
author_rank: Super Contributor
timestamp: May 03, 2013, 10:48:14 am
content: Quote from: amyk on May 03, 2013, 10:12:40 amMost 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 useif(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 asi = 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.

author: Kremmen
author_rank: Super Contributor
timestamp: May 03, 2013, 10:57:16 am
content: Quote from: amyk on May 03, 2013, 10:12:40 amAnd 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 Completehttp://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 Melhttp://www.cs.utah.edu/~elb/folklore/mel.html

author: BravoV
author_rank: Super Contributor
timestamp: May 03, 2013, 11:10:25 am
content: Quote from: jpb on May 03, 2013, 10:48:14 amIt 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 youwhinedproposed, how is that sound ?"

author: mikes
author_rank: Regular Contributor
timestamp: May 03, 2013, 12:07:08 pm
content: Quote from: Kremmen on May 03, 2013, 10:57:16 amThat'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.

author: jpb
author_rank: Super Contributor
timestamp: May 03, 2013, 12:39:42 pm
content: Quote from: BravoV on May 03, 2013, 11:10:25 amI 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.

author: Kremmen
author_rank: Super Contributor
timestamp: May 03, 2013, 02:48:12 pm
content: Quote from: mikes on May 03, 2013, 12:07:08 pmCircular? 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: May 03, 2013, 04:10:05 pm
content: Quote from: Kremmen on May 03, 2013, 10:57:16 ampft, to bad we don't own a farm

author: gautamdamodar
author_rank: Contributor
timestamp: May 03, 2013, 04:38:48 pm
content: -1

author: jmc2000
author_rank: Contributor
timestamp: May 03, 2013, 05:02:13 pm
content: 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.

author: kt315
author_rank: Regular Contributor
timestamp: May 04, 2013, 04:24:52 am
content: Quote from: MrPlacid on May 03, 2013, 07:53:30 amGood one. Are you still employed?

author: kt315
author_rank: Regular Contributor
timestamp: May 04, 2013, 05:00:31 am
content: Quote from: andyturk on May 03, 2013, 12:04:44 amDefine my_function as static and you'll be fine. Static functions have compilation unit visibility.

author: westfw
author_rank: Super Contributor
timestamp: May 04, 2013, 05:48:56 am
content: [quote ]I wish all the best to anyone implementing TCP/IP protocol in assembly 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.

author: lapm
author_rank: Frequent Contributor
timestamp: May 04, 2013, 08:11:34 am
content: 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...

author: Rick Law
author_rank: Super Contributor
timestamp: May 10, 2013, 05:38:04 am
content: Quote from: jpb on April 30, 2013, 09:02:20 pmIn 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

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 10, 2013, 01:00:53 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2013, 04:45:54 pm
content: 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'.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 10, 2013, 04:57:01 pm
content: 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.

author: ptricks
author_rank: Frequent Contributor
timestamp: May 11, 2013, 01:42:42 pm
content: 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/

author: Marco
author_rank: Super Contributor
timestamp: May 11, 2013, 03:26:18 pm
content: People creating high performance code generally build a mental model of the compiler by looking at the disassembled code, need to know assembler for that.

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2013, 05:35:53 pm
content: Quote from: ptricks on May 11, 2013, 01:42:42 pmYou can do exactly the same with C. These kind of (waste of time) projects keep feeding the myth that assembly is the way to write fast and small programs.

author: mazurov
author_rank: Frequent Contributor
timestamp: May 11, 2013, 11:04:38 pm
content: No matter how good your C coding skills are the initializer (standard routine that gets added to the beginning of the code to initialize statics and friends) takes some space, around 100 bytes for Microchip C compiler. I'm currently coding in assembly for tiny 256B ROM 16B RAM part for this very reason - next size memory size part is 10c more expensive and client is willing to pay for developing assembly code to save money in production.

author: Rufus
author_rank: Super Contributor
timestamp: May 12, 2013, 12:16:56 am
content: Quote from: mazurov on May 11, 2013, 11:04:38 pmThe timer example for a PIC12F1822 which I posted elsewhere compiles with Microchip XC8 to 75 instructions total. The 'initializer' consists of 3 gotos 2 file register clears and a bank select.A minimal C program for a PIC10F200 compiles to 6 instructions.

author: mazurov
author_rank: Frequent Contributor
timestamp: May 12, 2013, 02:36:28 am
content: Examples like that only prove that small C programs can in fact be produced. They won't prove that useful small C programs can be produced. In my experience (producing useful small programs), writing a C program for execution on a machine with limited resources often results in assembly program written in C syntax - no stack, no local scopes, minimal structure, etc.. Many times I found that writing such program in assembly makes it easier to code/maintain.

author: Rufus
author_rank: Super Contributor
timestamp: May 12, 2013, 02:55:24 am
content: Quote from: mazurov on May 12, 2013, 02:36:28 amIt proves that your claim thatQuoteIs crap - I was just being more polite about it first time round.

author: BravoV
author_rank: Super Contributor
timestamp: May 12, 2013, 03:12:42 am
content: Quote from: Rick Law on May 10, 2013, 05:38:04 amPersonal experience is major factor imo, like the OP which started his 1st mcu world using arduino, and then moved to GUI thingy "click & drag programming" using mouse with no or much less typing needed, hence appreciation on assembly language is obvious.

author: westfw
author_rank: Super Contributor
timestamp: May 12, 2013, 03:15:01 am
content: QuoteA good C compiler will let you omit that. "Optiboot", the bootloader for Arduino Uno, is under 512 bytes and written almost entirely in C. Suppressing the normal C startup code (and the rather large vector table that it includes) is a major part of that.Quote1) 1.44MB is pretty large. The original Mac had 128k of RAM...2) You shouldn't assume that it's "under 1.44MB" just because it fits on a single floppy. There are substantially useful versions of linux that fit on a single floppy, but they work by decompressing a filesystem into ramdisk.

author: mazurov
author_rank: Frequent Contributor
timestamp: May 12, 2013, 03:50:02 am
content: QuoteIs it this optiboot ->https://code.google.com/p/optiboot/source/browse/#hg%2Foptiboot%2Fbootloaders%2Foptiboot? If yes, then this is a good example of asm program in c syntax. The main loop (https://code.google.com/p/optiboot/source/browse/optiboot/bootloaders/optiboot/optiboot.c#472) is more than 150 lines long, the structure is kept as flat as possible, etc.. Also, just for fun, take a look inside boot.hBack in the days we were joking "you can write FORTRAN programs in any language". Certainly, no one knows what a FORTRAN is anymore but still - if your application requires structure of assembly language program, code it in assembly language.

author: Rick Law
author_rank: Super Contributor
timestamp: May 12, 2013, 04:20:43 am
content: Quote from: mazurov on May 12, 2013, 03:50:02 amNo joke, I saw an ad for a FORTRAN programmer back about 2 or perhaps 3 months ago. I didn't look at the details.

author: mazurov
author_rank: Frequent Contributor
timestamp: May 12, 2013, 04:22:10 am
content: QuoteWhat kind of rate were they offering?

author: Fsck
author_rank: Super Contributor
timestamp: May 12, 2013, 04:23:14 am
content: Quote from: Rick Law on May 12, 2013, 04:20:43 amIf you're a scientist, fortran and pascal are still common.

author: Bloch
author_rank: Unknown
timestamp: May 12, 2013, 05:47:14 am
content: Quote from: Fsck on May 12, 2013, 04:23:14 amOr in the Automation, it is hidden in IEC 61131-3 standard. Pascal are a much better than c for many things.

author: Rick Law
author_rank: Super Contributor
timestamp: May 12, 2013, 06:15:52 am
content: Quote from: mazurov on May 12, 2013, 04:22:10 amI really don't know. I did not look at the details. I was curious enough to checked it to see if it was for real, and it was. That was the only thing I checked.

author: westfw
author_rank: Super Contributor
timestamp: May 12, 2013, 07:08:21 am
content: QuoteYep.QuoteI won't disagree. It's a big case statement (except that if/else turns out to be slightly smaller) that implements a bunch of rather simple commands, so it wouldn't benefit a lot from the use of C "features." In fact, one advantage of coding it in real ASM might have been the ability to make the source layout more modularly grouped in spite of having nearly exactly the same structure.Quote(which contains a bunch of inline assembler for implementing various pieces of "self-programming" functionality.) Yep; exactly the sort of thing you need assembler for. Note that most of this is not used at all by the bootloader, and all of it is a slightly-modified version of a file from avr-libc that is normally provided with the compiler. There are several other strategic bits of inline assembler that I think are reasonable examples of cases where (inline) assembler makes sense.All of which has little to do with the point I was making that being coded in C did NOT automatically cause 100+ bytes of startup code to get included. Or any other overhead, for that matter.(BTW, I made a significant effort to see if I could hit the next-smaller bootloader size (256 bytes) by recoding the C in careful assembler. I pretty-much convinced myself that it's not possible. I MIGHT get a 256byte serial bootloader if I simplified the protocol, but that's a different solution.)

author: nuhamind2
author_rank: Regular Contributor
timestamp: May 12, 2013, 11:55:35 am
content: I also think everything I learn in uni is mostly useless.

author: Bloch
author_rank: Unknown
timestamp: May 12, 2013, 12:37:53 pm
content: Quote from: nuhamind2 on May 12, 2013, 11:55:35 amDo you learn c in uni ?

author: nctnico
author_rank: Super Contributor
timestamp: May 12, 2013, 12:54:16 pm
content: Quote from: mazurov on May 12, 2013, 03:50:02 amSorry but the point you are trying to make simply is not there... The C source is easy to read and porting it over to another microcontroller shouldn't be hard. Functions which do something with received data always look this way. Perhaps the author should have used a switch instead of if-else-if-else.

author: nuhamind2
author_rank: Regular Contributor
timestamp: May 12, 2013, 01:04:15 pm
content: Quote from: Bloch on May 12, 2013, 12:37:53 pmYes

author: Baliszoft
author_rank: Frequent Contributor
timestamp: May 12, 2013, 01:16:49 pm
content: "Anyone else think assembly is (mostly) useless?"No. Assembly rules forever!

author: westfw
author_rank: Super Contributor
timestamp: May 12, 2013, 08:05:46 pm
content: QuoteNah. PL/1, Fortran, Pascal, and Assembler. And some APL.(Hmm. Of those, the assembler is more akin to the assemblers I use now than any of the other languages are similar to the C/C++/Java/Perl/etc that are popular HLLs today... An odd thought.)

author: SolarSunrise
author_rank: Regular Contributor
timestamp: May 14, 2013, 07:20:12 pm
content: I mostly program in Assembly to understand the system architecture (I program a 32 bit 168Mhz ARM Cortex M4 in Assembly. It's the best way to get friendly with your complex micro-friend).Also, it comes in handy when you are doing DSP's and other real time processing. But C can do as good as assembly if you code efficiently.

author: westfw
author_rank: Super Contributor
timestamp: May 15, 2013, 12:52:08 am
content: QuoteAlso, the reverse: "Assembly language can be as bad as C code if you DO NOT code efficiently."This is a pretty key point; programming well in assembly is more difficult than programming well in a HLL. Especially if you're trying to keep it up over all of 100k of object code. Or 30k. That pic10f with 512 instruction words; not as much of a problem...

author: Kremmen
author_rank: Super Contributor
timestamp: May 15, 2013, 06:44:10 am
content: Quote from: westfw on May 15, 2013, 12:52:08 amI think there is a point here: Debating whether to code for a 512 byt program space in asm or C or some other HLL is essentially fruitless. Whatever your choice you won't have much of a structure or complexity in such a miniscule space.Conversely, the logic of choice in such a small environment and the logic of choice for a much larger environment are 2 different things and should not be approached equally. You can easily walk to the corner store but a holiday trip to Thailand (Hawaii for the yanks) means an airplane ticket. Same thing.

author: AlfBaz
author_rank: Super Contributor
timestamp: May 15, 2013, 09:16:20 am
content: Quote from: Kremmen on May 15, 2013, 06:44:10 amI think you've hit the nail on the head here.It seems it has more to do with the definition of embedded or more precisely the perspective one takes when considering an "embedded project".Given that some MCU's these day's have resources equivalent to or even exceeding PC's of about 10 years ago it becomes very inefficient to consider not only low level languages but the software platforms on which they are built.Some small 8 bit architectures are not designed with C in mind and C compilers written for these things generally produce horrible convoluted output, namely because the big players don't put in any significant development into a compiler that isn't going to sell much.As for the comment that C can produce code as good as assembly, on some architectures its almost impossible to write assembly that's as good as the compiler because its very difficult to keep track of what combination of instructions will cause pipeline stall. It aslo makes it very difficult to follow the output

author: cthree
author_rank: Frequent Contributor
timestamp: May 18, 2013, 06:14:43 am
content: Assembler has a narrow use case. Any more than 10 lines and it should be done in C.Rarely can an engineer, let alone a true programmer do a better job hand stitching assembler than a modern C toolchain can. There is nothing you can do in assembler that you can't do in C, better, faster, cheaper and with fewer bugs and fewer maintenance headaches. I'll take the 0.01% inefficiency for the smallest most trivial programs in favor of the 99.99% extra efficiency in everything else.If you reach for Assembler, you probably don't know C well enough but I would suggest, as a software guy primarily, you would gain way more by becoming a C expert than you would lose by letting Assembler go. C gives you a vast array of tried and true libraries of code, much of it runs the same on an AVR as a 8051 or a PIC or ARM. How many Assembler variants and datasheets are you going to remember?C makes you flexible, pragmatic.

author: TheWelly888
author_rank: Frequent Contributor
timestamp: May 26, 2013, 02:37:31 pm
content: I don't like assembly, I just discovered this new language....http://en.wikipedia.org/wiki/Brainfuck...coat on and gone...

author: gerrysweeney
author_rank: Regular Contributor
timestamp: May 30, 2013, 12:44:33 pm
content: For what its worth, I started my programming journey many years ago in assembler on 6502, Z80 and then X86/286/386 and very quickly got to C and then C++ after that. I would say that assembler has a very important role but in an increasingly narrow area. CPU's and micros are bigger and faster and cost so much less today so buying more grunt to get past the overhead of language calling conventions etc is well worth the cost in time saving which is way more expensive. That being said, sometimes, and especially in interrupt routines where timing is critical, then hand cranked assembler can win out where it needs too - so long as the developer is competent - it takes a lot of experience and an in depth understanding of the specific architecture to make it worthwhile. In my recent project on PIC's I have used pure C, even for the interrupt handlers because I had the headroom on the target device. If I were to write a lernel-level hardware device driver on the X86 Windows or Linux platform I would almost certainly use some small amount of in-line assembler to guarantee precise behaviour and optimisation of the stack bashing needed to make stuff work reliably and quickly, but apart from the frame setup it would all be C after that.I don't think you can be generic with this view, you need to be objective and look at it on a case-by-case basis. If you are a competent assembly programmer you will by definition have a thorough understanding of the platform you are targeting. It would be no surprise to know that the people that can really drive a RealICE debugger and diagnose system level hardware or software issues with such a tool would be very proficient in understating machine code...the two things go hand in hand.Gerry

author: andyturk
author_rank: Frequent Contributor
timestamp: May 30, 2013, 09:41:14 pm
content: Quote from: TheWelly888 on May 26, 2013, 02:37:31 pmDo you one better...http://code.kx.com/wiki/Startingkdbplus/contentskdb+ is a proprietary language that's used every day by quants on Wall St. It's a descendant of APL with some LISP and SQL thrown in. The entire executable is *under* 500Kb, and that includes a relational database implemented in the language.The attached image is what kdb+ code looks like. I think that's the SQL parser.