OSDev.org

For most programmers, is necessary currently develop in machine code and assembly?

I am so curios in this topic because I like the subject and I've heard that assembly code is extremely expensive, if it's true that assembly code is extremely expensive, I'll try to make lots of money programming in assembly.

manhobby wrote:For most programmers, is necessary currently develop in machine code and assembly?

No.

manhobby wrote:I've heard that assembly code is extremely expensive, if it's true that assembly code is extremely expensive, I'll try to make lots of money programming in assembly.

Good luck finding such a job!

Hello manhobby,

manhobby wrote:For most programmers, is necessary currently develop in machine code and assembly?

I am so curios in this topic because I like the subject and I've heard that assembly code is extremely expensive, if it's true that assembly code is extremely expensive, I'll try to make lots of money programming in assembly.

My younger self used to believe that being a rock star programmer will make you rich/popular. Money is in your ideas ( and your execution, marketing etc ), how to come up with something that is useful to people so that they will spend some $$$. Also I believe coding is one of the most trivial parts of the job, Anyone can code once they get used to the syntax. I like to spend more time thinking than coding. These are after all my personal opinion. Have fun!.


--Thomas

alexfru wrote:

manhobby wrote:For most programmers, is necessary currently develop in machine code and assembly?

No.

Why no?

manhobby wrote:For most programmers, is necessary currently develop in machine code and assembly?
Why no?

Most software is written in a higher level language like C, Java, PHP and others. As for the reason why, assembly is not a very efficient way to code. The only time assembly is used in the industry today is when there are no other alternatives, and there are few time where that is the case.
This is why knowing assembly is not a very valuable skill for your career, there are very few times cases where a company needs to hire an assembly programmer.

manhobby wrote:

alexfru wrote:

manhobby wrote:For most programmers, is necessary currently develop in machine code and assembly?

No.

Why no?

Multiple reasons:

• Not every programmer implements operating systems or compilers and things alike, where knowing assembly is a must (actually, you can probably translate to C instead of assembly/machine code)
• It's not easy or fast to write the best assembly code by hand
• It's not always needed, we've got very good compilers and computers these days
• Specifically, manually optimizing assembly code across multiple logic layers/subroutines is going to be a nightmare, but C++ compilers can just do it
• Assembly code is poorly portable between different architectures
• Maintaining and changing asm code isn't easy/fast
• And I think we change code more often these days than we used to, which favors development in higher level languages

Knowing algorithms and computer architecture is usually more important than assembly details.

I will add that everything Alexfru said about assembly language applied doubly to machine language, which is, after all, what assembly language was created to abstract away. While legendary machine code programmers such as Mel Kaye evoke awe and respect, you should note that even in 1959, when that story took place, machine code was mostly a lost art - and for good reason - and even assembly programming was beginning to wane. The term 'real programmer' is a sarcastic one, one tinged with both grudging respect and eye-rolling derision, the sort of response people give to someone who has memorized pi to 100 places - an impressive feat, but also a mostly useless one.

Both methods did see revivals, both on the mini-computers when they arose in the 1960s, and in the 1970s for the early microcomputers such as the Altair 8800, KIM-1, and COSMAC ELF, but even then it rapidly vanished again as more sophisticated development systems took root for those machines. Note that even for the Altair (the first widely used microcomputer), the first major application was a BASIC interpreter, the very one which put Microsoft on the map. Even earlier, one of the first big programs for the TX-0, and again on the PDP-1, was a Lisp interpreter - indeed, the first REPL was on the TX-0, as was one of the first garbage collectors, which were developed to deal with the limited memory on systems of the time.

While machine code and assembly language have always had some enthusiasts, and probably always will, most programmers only resort to them if they have no other alternative - something that almost never happens today for ordinary programming. High-level languages are the rule of the day now, and have been for over fifty years.

Indeed, on most current systems, writing raw machine code is generally impractical, bordering on impossible, except for making quick fixes in an executable debugger (and even then, most debuggers will accept assembly code, and display it, rather than force you to work in the hex or octal code directly). In almost any real-world programming outside of OS dev and a handful of embedded systems projects, you are working with code compiled or assembled to an Object File in an Executable Format, rather than a raw binary image, and won't even launch a program if it isn't in that object format.

For that matter, many programs today aren't compiled to native code at all, but to an interpretable bytecode or some other other intermediate form; even those which do eventually get turns into native code are generally loaded from a bytecode format, and compiled Just-In-Time by the language system. And that's before we even bring up the web browser and web server based languages such as PHP and JavaScript, which are the overwhelming majority of current-day programming for all but a handful of application and systems programmers.

Schol-R-LEA wrote:I will add that everything Alexfru said about assembly language applied doubly to machine language, which is, after all, what assembly language was created to abstract away. While legendary machine code programmers such as Mel Kaye evoke awe and respect, you should note that even in 1959, when that story took place, machine code was mostly a lost art - and for good reason - and even assembly programming was beginning to wane. The term 'real programmer' is a sarcastic one, one tinged with both grudging respect and eye-rolling derision, the sort of response people give to someone who has memorized pi to 100 places - an impressive feat, but also a mostly useless one.

Both methods did see revivals, on the early mini-computers arose in the 1960s, and again for the early microcomputers such as the in the 1970s, but even then it rapidly valished again as more sophisticated development systems took root for those machines. Note that even form the Altair, the first major application was a BASIC interpreter, the very one which put Microsoft on the map. Even earlier, one of the first big programs for the TX-0, and again on the PDP-1, was a Lisp interpreter - indeed, the first REPL was on the TX-0, as was one of the first garbage collectors, which were developed to deal with the limited memory on systems of the time.

While machine code and assembly language have always had some enthusiasts, and probably always will, most programmers only resort to them if they have no other alternative - something that almost never happens today for ordinary programming. High-level languages are the rule of the day now, and have been for over fifty years.

Indeed, on most current systems, writing raw machine code is generally impractical, bordering on impossible, except for making quick fixes in an executable debugger (and even then, most debuggers will accept assembly code, and display it, rather than force you to work in the hex or octal code directly). In almost any real-world programming outside of OS dev and a handful of embedded systems projects, you are working with code compiled or assembled to an Object File in an Executable Format, rather than a raw binary image, and won't even launch a program if it isn't in that object format.

For that matter, many programs today aren't compiled to native code at all, but to an interpretable bytecode or some other other intermediate form; even those which do eventually get turns into native code are generally loaded from a bytecode format, and compiled Just-In-Time by the language system. And that's before we even bring up the web browser and web server based languages such as PHP and JavaScript, which are the overwhelming majority of current-day programming for all but a handful of application and systems programmers.

Schol-R-Lea, you was very detail, thank you.

Thanks you to all that responded correctly.

Good luck to all that responded correctly!

Schol-R-Lea, did you learn the answer that you said in this topic in which source?

For example, you said that while machine code and assembly language have always had some enthusiasts, and probably always will, most programmers only resort to them if they have no other alternative - something that almost never happens today for ordinary programming.

Schol-R-Lea, in which source did you learn that while machine code and assembly language have always had some enthusiasts, and probably always will, most programmers only resort to them if they have no other alternative?

Please, sorry if my English is not good.

People program in the way they do either because they're more comfortable working that way or because they're looking for gains (or in many cases both). Operating systems written using assembler only (or direct machine code) tend to be much more compact than others written using compilers without necessarily losing performance. More compact code means that it's faster loading (which for a lot of code is more important than the speed it runs at), but it also allows you to have more functionality sitting in memory without the need to keep swapping things to disk. That doesn't mean that a compiler couldn't produce the same compactness of code if it was designed to do so, and there will soon come a point where anything written by a team of the world's best assembly and machine code programmers can be matched by a compiler, so it's clearly an art that's heading for extinction.

Where high speed is essential (inner loops, mostly), it is still possible to make gains by manually exploring different alignments of code and changing the instruction order. I recently found that a routine with lots of nested loops in it ran fastest not by aligning jumps to addresses that are multiples of 4, 8 or 16, but by pushing the whole lot out of alignment by a couple of bytes, and this happened even though the start of a loop ended up a couple of bytes ahead of the start of a cache line. Moving a write instruction into an inner loop also speeded it up a fraction, because even though that led to enormous numbers of unnecessary extra writes, they were carried out for free during a simultaneous read, and it turned out that not having to do a write after exiting the inner loop resulted in a speed gain. Following the rules will get you close to optimum performance, but experimentation can sometimes get you a fraction closer in unexpected ways. However, such gains may be processor specific - run the same code on a different machine and you may need a different alignment to get the best performance. Such gains are also trivially small, so it's rarely worth the effort.

Better compilers will eventually eliminate the gains entirely (if they run tests with many different alignments, tuned to specific machines) and lead to assembler and direct machine code programming being useful only for educational purposes (to show people how computers work), but it will still be essential for compiler writers to understand machine code well, because they are writing programs that write machine code, so that's the place to apply such expertise rather than training yourself to write code at low level yourself.

I personally do all my OS-related programming in machine code, but my aim has always been to build something that will eliminate my need to do so - I feel more comfortable working with the raw numbers than using abstracted programming languages which are so complex that most of the bugs I get when using them are the result of not understanding quirks of the programming language. I find programming languages suffocating, whereas I actively enjoy working in machine code - it just suits the way I think. This shuts me out of working on anyone else's project though (whether for fun or to earn money), because I don't have sufficient knowledge of any of the programming languages they use (not even assembler). However, I want to switch over to using natural language for programming instead, because that would suit me much more - I already know the rules my native natural language without having to study anything, and there are no pitfalls hidden in it. The natural language compiler that I'm currently trying to build will be part of an AGI system which crafts every byte of its code like a perfect machine code programmer, and while I only know z80 and x86 machine code (and don't use the full range of available instructions), AGI will eventually have complete mastery of the machine code of all processors, eliminating all portability issues.

What about earning money? Well, I doubt anyone earns anything by writing directly in machine code, and while some assembly programmers may be paid a lot for their work, I doubt there are many vacancies for such work - there can't be much of it that needs to be done, and any company that needs it for something will already have someone with the relevant expertise on their books. There's more chance of making money elsewhere, but you should be aware that programming jobs are not going to be secure forever - automation will begin to eliminate large numbers of them during the next decade, and the people who last longest will be the most creative ones and the best problem solvers. The rest will struggle to find or stay in work. Human machine code programming and assembler are already on the edge of extinction, but all specialist programming languages will soon follow them. Anyone who wants a secure future in programming needs to have something extra to offer - some kind of skill that will keep them in demand: perhaps artistic flair, good sales pitch and personal relations, or just sheer inventiveness. Those who lack such a special skill will have no future in this industry.

I have another prediction that I'll just throw in here too: that security will become less of an issue as all programs will be written locally on the machine they run on, compiled by AGI from high-level natural language programs in which it's impossible to hide malicious code. There will be no need to keep anything in the machine hidden from any process, so memory management can be switched off without compromising security whenever that leads to a speed gain, and any processor that doesn't allow this will be seen as defective. Scripting languages on web pages will also be replaced by high-level natural language, and again it will not be possible to hide malicious code there. This will lead to a great simplification as everything switches over to one unified way of working, removing tons of unnecessary junk from every OS and app, and in the process wiping out most software companies, including some of the big ones. The future of work in this industry is not secure.

Wow, the sense of deja vu is almost overwhelming. This is almost an exact repeat of the conversation with Trident from about three years ago to a certain lingering infamy.

As for how I know it... well, first off, because I have been programming for over 30 years and have never had a paid position in which assembly language was used at all. I have used it in OS-dev, if course, and in other personal projects, but as far as professional programming, most professional programmers whom I have known didn't even know assembly at all, and if any knew how to write machine code, it was never mentioned. Even for those who did know assembly, most would probably have turned down a position in assembly programming, and probably would have considered the ones hiring for such a position to be insane.

I doubt that most programmers would even recognize an assembly program, if handed a listing of the source code. They would probably think it was some kind of cipher, or an esolang such as Befunge.

The jobs which do exist for assembly programming are few and far between, and while an experienced assembly programmer will often get paid very well for it, it is their experience - experience over decades of low-level programming, in most cases - that they are paid for. A novice assembly programmer probably wouldn't find a job for that niche, and if they did, they would probably get paid far worse than most other programmers (if they actually got their paychecks at all), as the sort of company that would have such a novice assembly programming position is likely to be pretty fly-by-night.

A more reputable company might have what would be essentially an assistant or apprentice position training under a master assembly programmer, to try and train the newbie up for when the master retires, but it would be very rare to find something like that, and would earn trainee salaries for at least a few years. Such a job would be very specific to the hardware, as well, probably in some kind of highly specialized embedded controllers (as even those are mostly programmed in high-level languages these days) and the position would be tightly bound to the success of that specific company.

To the best of my knowledge, most but not all universities do still have an assembly language course, though hardly any make it a requirement any more, and I doubt more than one student in twenty take such a course if it isn't required for their degree. When I returned to college in 2006, the school I went to (California State University, East Bay) did require it for a BSCS major, and the course I took was in MIPS assembly (using the SPIM emulator rather than actual MIPS hardware), but most such courses would be on x86 assembly, though ARM assembly is gaining interest with the rise of the Raspberry Pi.

I had been programming for years at that point, and had learned quite a bit about x86 assembly language on my own by then, so the course was at least somewhat familiar ground for me. Most of the other students struggled a lot more in the class, as it was something most had never seen before even though many had been programming in high school.

Now, I am something of an oddity, in that I am interested in working in machine code (for reasons of my own, mostly relating to the design and development of new high-level languages). A few others here (such as DavidCooper) work in machine code as well, and quite a few work in assembly by preference; it is simply a part of OS dev, so anyone here will end up using it to some degree, though most prefer to use C or another systems programming language where possible. But it isn't necessary except in a few specific areas, in in OS dev - mostly in the booting and early system setup, and as a way of improving performance in critical paths - and not everyone here is particularly fluent with it.

However, OS dev is very, very out of the norm. For most people who aren't working in either operating system development, or compiler development, assembly language is neither necessary nor desirable, as the name of the game in most programming is abstraction - and assembly language is about as low a level of abstraction as you will find.

Schol-R-LEA wrote:because I have been programming for over 30 years

Can you show some example?

igorov70 wrote:

Schol-R-LEA wrote:because I have been programming for over 30 years

Can you show some example?

I suppose I could point you to my GitHub repos, but most of the projects in those are... incomplete, to say the least, as motivation and follow-through are serious problems for me.

A lot of the more complete programs have long since been lost over the course of time, especially those from before Sourceforge made offsite repositories a commodity service.

For professional projects, well, it isn't as if I own any of the code I wrote for other people.

In any case, I don't think you necessarily want to use my code for examples. I have been doing it for a long time, but that doesn't mean I am any good at it - and since the question was about what sort of programming companies hire people for, it really wasn't relevant to the topic. All I can tell you is what I have seen people using, which these days is mostly garbage such as PHP and JavaScript, with tons of frameworks doing the bulk of the work - badly designed languages being used badly.

Schol-R-LEA wrote:those are... incomplete

No offense but you stop tell people your 30 year long experience if you have zero experience. My last 3 job: 1 was writing microcode, 2 was writing code for a microcontroller, 3 was security audit of a remote controlled entrance system, all of them was in assembly. You making nonsense.

igorov70 wrote:

Schol-R-LEA wrote:those are... incomplete

No offense but you stop tell people your 30 year long experience if you have zero experience.

I did not say I have zero experience. I said experience alone is no indicator of capability. I have known plenty of programmers who have been coding in JavaScript for 20 years, or COBOL for forty, but have no knowledge of anything else (and a most of them don't really know their 'specialty' that well, either).

My own experience is rather more diverse than that, but I have the opposite problem: I have gone in so many different directions that I have not really become an expert in any one of them. Still, my experience ranges from MS Access to C++, from JavaScript to Java, from C to Scheme (OK, that last one wasn't professional, but it is my favorite), and from Python to Perl, with detours into Ruby, PHP (ugh), Common Lisp, BASH shell scripting, Applesoft BASIC (which I actually did get paid for, believe it or not, though the circumstances were very odd), FoxPro (my first 'real' programming work, for the same one who had me maintaining his Applesoft BASIC code, though what I wrote for them was utter garbage which I am rather ashamed of now), Visual Basic (double ugh) and VB .Net, C#, Delphi (and again, this was a paid job despite the rather low adoption of that language, and I think I did keep the code for that; I may even have it backed up somewhere, but I would need to find it), and even Ada (for a course, but still). Oh, and tons and tons of HTML and CSS, but we were talking programming, not markup...

I am fairly well versed in x86 and MIPS assembly, though by no means an expert, and have some understanding of ARM assembly, and even some vague recollections of 6502 assembly programming for the Apple II from long ago (I don't even remember what I was trying to do with it, I was probably just messing around with it for fun). But at no time was I paid for assembly programming, and the number of people under the age of sixty who have done so, whom I personally know, could probably be counted on one hand.

So yes, I have been programming for three decades, in various capacities, some of which were professional. But all of that experience doesn't make me a great programmer. I will leave it to others to judge how capable I am, as I am, needless to say, far from objective on that.

igorov70 wrote:My last 3 job: 1 was writing microcode, 2 was writing code for a microcontroller, 3 was security audit of a remote controlled entrance system, all of them was in assembly.

Microcode? Seriously? Who the hell were you working for, Global Foundry? There are probably been less than twenty thousand programmers worldwide that have worked on microcode in the past fifty years, most of them now long retired! Given your name and stated location, I might believe you if you say you are working for T-Platforms... except that their licensed MIPS and ARM systems wouldn't be using microcode, since avoiding microcode is one of a main points in RISC designs (even if ARM has been playing fast and loose with the definition of 'RISC' since the early 2000s...).

Oh, and microcode design would not itself be primarily writing in the CPU's assembly language - it would be implementing the assembly language (or rather, the machine code), in a lower-level instruction set. It is an assembly language itself, true, but not one anyone who isn't working on the design of the CPU would ever see.

I should also mention that since the mid-1990s, even most CISC architectures forego the traditional types of microcode in favor of dynamic binary translation, but that's splitting hairs.

Or did you mean 'firmware' instead (BIOSes and the like)? That's something a bit different; microcode is a type of firmware, but not one you normally have any access to unless you are designing the ISA itself, and most firmware isn't microcode. I know some people call all firmware 'microcode', so I am guessing that this is what you were talking about. That would be a lot more believable a claim, as that is a great deal more common and does indeed usually demand a lot of assembly coding, though even then it is, shall we say, a bit implausible that you have done this professionally.

Similarly, very, very few places anywhere still use assembly as the primary language in micro-controller programming - it is often part of it, yes, but even when I started out studying programming back in the late 1980s, most embedded programming was already moving to C.

To say that I am extremely skeptical of what you are claiming would be a massive understatement. I don't want to assume that it isn't true, but at the same time it seems more than a little hard to swallow (even for me!).

You making nonsense.

I am pretty sure I am not the one talking BS here, especially since your profile states that you are student - and while it may be that you are a returning student, as I was, your other posts are vague enough that I would have to wonder why you insist on answering questions with vacuities rather than actually contributing (a behavior most associated here with spammers who are trying to go around forum minimum posting requirements - not a good look for you if you aren't trying to do that, a pretty clear tell if you are). If you were what you claim to be, I doubt that you would be wasting your time on a hobbyist message board like this one.

igorov70 wrote:

Schol-R-LEA wrote:those are... incomplete

No offense but you stop tell people your 30 year long experience if you have zero experience. My last 3 job: 1 was writing microcode, 2 was writing code for a microcontroller, 3 was security audit of a remote controlled entrance system, all of them was in assembly. You making nonsense.

You joined yesterday and nearly every post you've made seems like flame-bait. Even if everything you're saying is true and not just puffery it doesn't mean anything to say that you use assembly in your work because it doesn't disprove what Schol-R-LEA is saying. He's saying assembly positions are rare and that it's not a lucrative career option because there isn't a very high demand.

The skill which makes some assembly coders very valuable is their hardware knowledge, which is to do with experience, not the language they use.

And don't claim people have zero experience when it's obviously not true. It's quite rude.