I dont think so.C is low level enough to deal with memory mappings.However if your device for some reason cant hold a C compiler(it is a bare microprocessor) then sure assembly is used

I don't know if this is actually what you meant, or if you meant if the device can't hold a compiled C program. As already pointed out, you wouldn't run the compiler on the microprocessor -- you'd compile the code on a full-up computer and then download it to the processor.

But there is the issue of a micro being so limited that it can't hold the compiled program. Some micros only have 24 total bytes of RAM (for instance, the PIC16C55, though I don't know if there are any others). While there are C compilers that will target these parts, it is challenging. But since these parts also have very limited instruction ROMs, it is common practice to handcode programs in assembly for parts like this and the limited ROM size keeps the program complexity manageable. That same limited code size also makes it so that the programmer often has to come up with very clever tricks to get the desired functionality to fit within the available space, and these are things that compilers can struggle with.

 

I have programmed PIC12C508 by hand. It has 512 locations of code space. Amazingly, I developed a technique whereby I could fix bad code and keep on doing this until I ran out of memory space.

 

I don't know if this is actually what you meant, or if you meant if the device can't hold a compiled C program. As already pointed out, you wouldn't run the compiler on the microprocessor -- you'd compile the code on a full-up computer and then download it to the processor.

But there is the issue of a micro being so limited that it can't hold the compiled program. Some micros only have 24 total bytes of RAM (for instance, the PIC16C55, though I don't know if there are any others). While there are C compilers that will target these parts, it is challenging. But since these parts also have very limited instruction ROMs, it is common practice to handcode programs in assembly for parts like this and the limited ROM size keeps the program complexity manageable. That same limited code size also makes it so that the programmer often has to come up with very clever tricks to get the desired functionality to fit within the available space, and these are things that compilers can struggle with.

What I mean is this:
In order to translate C into lower level languages you need another program which usually gets downloaded along with the IDE.Without the C compiler the computer doesnt know how to translate C into lower level languages (assembly and machine code).None microprocessor doesnt have pre-installed the C compiler nor does it have a operating system so you cannot directly write code using C for a microprocessor.

 

I am not sure what you are saying.
Here is what most of us understand.

MCU does not run C compiler.
C compiler runs on a PC.

 

What I mean is this:
In order to translate C into lower level languages you need another program which usually gets downloaded along with the IDE.Without the C compiler the computer doesnt know how to translate C into lower level languages (assembly and machine code).None microprocessor doesnt have pre-installed the C compiler nor does it have a operating system so you cannot directly write code using C for a microprocessor.

I don't know if you realize it or not, but there is a distinction between a microcontroller (MCU) and a microprocessor (MPU) -- though the lines have become pretty heavily blurred in recent years (the last couple decades or so).

Traditionally, a microcontroller was a very limited microprocessor combined with the kinds of on-chip peripherals that were commonly used for embedded systems work. This very commonly involves the use of a Harvard architecture in which the program was loaded into a separate ROM, meaning that once the program was downloaded to the MCU, it could never be changed (though some parts could be erased and rewritten, but these were expensive versions intended for development work). Today, most MCUs use Flash memory making them much more reusable. The reason for the Harvard architecture in MCUs is because they are typically used for dedicated embedded systems and so they only run a single program for their entire life and it makes sense to store it in ROM that is immediately accessible to the processor on power up. But there's nothing that says that an embedded system must use a Harvard architecture and general purpose MPUs, most of which use a Princeton architecture, are widely used in embedded systems. Some of these have operating systems and some run on bare metal.

But this is largely a separate issue from whether a compiler can run on the processor. A compiler is nothing more than program that takes input files containing source code and produce output files containing executable opcodes. If you can write the compiler program so that it can run in the amount of memory available to the processor and if it can access the source code files and write the executable files (or store them in RAM where they can be executed), then your compiler can run on that hardware.

A classic case is the C compiler used to write the Unix operating system. As is almost always the case, the initial implementations were bootstrapped and small core programs were written on a different machine and transferred to the PDP-11. But eventually the PDP-11 had the ability to run programs natively that could edit the source code files, compile them to object code files, and link the object code files to produce the final executable, which could then be run on the same machine. Fundamentally, there is nothing that requires cross-system development for the early work, it's just much easier. After all, the very first computers had no "other computers" to do the cross-platform development on.

To put this into perspective, the PDP-11/40 that this was done on had a whopping 24 KB of memory (12 K 16-bit works). Today, cheap MCUs like the MSP430 have as much as 64 KB or RAM.

The first computers I worked with had 4 KB of RAM and I could run compilers on them with no problem. Some didn't have an operating system, just a BASIC interpreter (which has to do everything a compiler does and then some) that loaded, edited, saved, and ran programs within the interpreter environment.

 

There was the PICAXE. That had the compiler built in, or was it is an Interpreter?

to me, the Microprocessor/microcontroller distinction Is “does it have peripherals?.”

 

PICAXE runs a BASIC interpreter.
There is also Forth (again interpreter) that runs natively on many microcontrollers.

One of the fastest and efficient compilers was Turbo Pascal that ran straight out of 640KB RAM on 8080/86 processors.

 

Hi everyone,

I am very curious - do engineers still use assembly language in their design nowadays? If they do, where would they typically use it?

Thank you! I am very curious about this subject.

Your question is interesting. Nowadays, most engineers write C/C++ (or higher-level languages) for the vast majority of systems but the Assembly hasn’t disappeared. Mostly, the language depends on the particular application and assembly language is still in use but in very less cases.

 

I wouldn’t think much new code would be written in Assembly language these days, a few years ago I thought of going back to organisations that still use zOS but all the work I could find was short contracts to convert the code to C/C++. It’s just that many of the programmers that used those skills are retired now. I’m not far off either.

Ron

 

I wouldn’t think much new code would be written in Assembly language these days, a few years ago I thought of going back to organisations that still use zOS but all the work I could find was short contracts to convert the code to C/C++. It’s just that many of the programmers that used those skills are retired now. I’m not far off either.

Ron

Assembly is very important tho.I myself dont write in assembly unless I design a custom microprocessor but this is a mistake.How would you code a kernel of a operating system without assembly?

 

Assembly is very important tho.I myself dont write in assembly unless I design a custom microprocessor but this is a mistake.How would you code a kernel of a operating system without assembly?

That's a fascinating question. I suspect that with a suitably designed language it might be achievable.

Many modern compilers use LLVM (in essence an abstract processor with infinite registers) as the back end, that itself exposes a host of system oriented intrinsics, so with sufficient motivation I believe a target independent mechanism could be designed.

For example allowing stack pointer manipulation as an innate language feature for example.

 

That's a fascinating question. I suspect that with a suitably designed language it might be achievable.

Many modern compilers use LLVM (in essence an abstract processor with infinite registers) as the back end, that itself exposes a host of system oriented intrinsics, so with sufficient motivation I believe a target independent mechanism could be designed.

For example allowing stack pointer manipulation as an innate language feature for example.

But, at the end of the day, it still has to end up as machine code and that means the path pretty much has to go through assembly language at some point. Plus, you want many of the core services of an OS to be as tight and efficient as possible, and that will likely always mean hand coding, or at least tweaking, in assembly language instead of accepting the overhead associated with translating from the abstracted and more generic virtual machine.

 

But, at the end of the day, it still has to end up as machine code and that means the path pretty much has to go through assembly language at some point. Plus, you want many of the core services of an OS to be as tight and efficient as possible, and that will likely always mean hand coding, or at least tweaking, in assembly language instead of accepting the overhead associated with translating from the abstracted and more generic virtual machine.

I wasn't suggesting any kind of runtime VM. The LLVM backend system is a (huge) translator for the abstract machine IR to the target machine. It has very impressive optimizations and generates very efficient target code.

It's invisible to the programmer, it's just a phase in the compilation process, no runtime component to it.

It provides a wealth of features only some of which are exploited by most languages. For example it offers arbitrary precision integers - 5 bit, 17 bit, 43 bit, whatever, and exposes intrinsics for saturated arithmetic. It supports binary fraction arithmetic with arbitrary precision and scale.

Recent versions of C have a bunch of directives that tap into these kinds of things but they are an after thought.

I just think its interesting to consider what we use assembler for in (say) an OS and ask could that be eliminated by adding some capabilities to a language, like for example exposing the stack pointer and stack frame etc as first class language features.

You might want to take a look, if you use Clang I think you can ask it to generate LLVM source code (not just target processor assembler) and see the abstract assembly it generates. If you have LLVM itself you can compile LLVM source text to any target and platform (Windows, Linux, Mac etc).

It is based on a technique called SSA, and that is part of the foundation that makes it an efficient code generator with a huge array of optimizations.

I don't think anyone has designed a language from scratch to take advantage of these LLVM features, making them simply part of the language. Many languages have used LLVM but many of these more esoteric features are "boltons" so to speak.

Here's an example courtesy of Copilot:



If we were to look at the final code generated for say ARM32 or something, we'd see a very compact efficient result, that IR code goes through numerous aggressive optimizations (many of which used to be the province of the compiler itself).

So LLVM can allow us to pretty much forget about the actual target CPU altogether and we can just think at the IR level, but there's a price to pay and that is that LLVM is big, quite complex and not trivial to get used to.

Also a real compiler doesn't generate LLVM IR text (but it could) instead it uses a C++ API that mirrors the LLVM operations and that class library is complex and idiosynchratic, very doable but takes some time to learn. Many cutting edge compilers use LLVM, you might even use one and have no idea that LLVM is used:



I built the entire LLVM system on my desktop last year, took over 2 hours and it isn't small machine.

 

One of my favorite designs was a LED replacement for an incandescent light bulb. Customer specified the LED, a curve of brightness over the input voltage range of 8 to 28VDC. The polarity of the input could swap, and the whole thing had to fit into a metal can about the size of a pencil eraser holder.

OK, bridge rectifier, micro controller,LED and its driver all had to fit. Used a Microchip PIC with a shunt power voltage regulator, tiny bridge, dual transistor package in a constant current configuration to drive the shunt regulator, and another transistor for the LED driver; driver was an emitter follower with the LED between the collector and power to the PIC could PWM the current.

Controller had to read the input voltage (A2D), compute the PWM ratio, and pulse the LED. The pulse width was computed from a list of widths vs voltages that was used in a linear interpolation to compute the final pulse width. A simple calculation of A*B/C.

The code needed to fit into the tiny PIC, having but 1000 instructions. I wrote it in C. All was well until I added that division, which blew up the binary to several K words. So... I did the division by subtraction in a loop.

It fit! And the initial prototype passed the check by my customer. Unfortunately the product never made it to production, but it was very fun!

Writing this in assembly was never considered.

 

My first introduction to programming and assembly was with the PDP-8, working controlling an early CNC machine, where someone had taken a data processor and used it for industrial application,
Soon after it was with the Intel 8080 - 8085.
Since that, I have always leaned to the assembly side of things.

 

My first introduction to programming and assembly was with the PDP-8, working controlling an early CNC machine, where someone had taken a data processor and used it for industrial application,
Soon after it was with the Intel 8080 - 8085.
Since that, I have always leaned to the assembly side of things.

Another classic ASM first experience. There were only eight groups of machine instructions. Eventually, you learned when all by heart, in octal!

I was able to enter the entire RIM (Read-In Mode) machine code straight from memory (16 instructions, see the code under the ASCII code table). You carried this card around with you in your shirt pocket.

Those were the days!

 

I've known a couple of folks that spent so much time with hex dumps for a particular processor (don't recall which ones) that they could read them as easily as assembly language.

 

I've known a couple of folks that spent so much time with hex dumps for a particular processor (don't recall which ones) that they could read them as easily as assembly language.

My first contact with computers was on a CDC6400 mainframe. You created the program on punched cards and submitted the card deck with a job ticket via the window to the computer room. Then you waited 2-4 hours for a computer printout on 15-inch wide computer paper with the tear-off perforated margins.

IF your program crashed, the printout was a "core dump". Then you stood in line to see the computer systems analyst who would read the core dump and hopefully try to tell you what when wrong. Three or more tickets later, maybe you got a successful output. If you ran out of tickets you had to go beg the course instructor for extra tickets.

 

My first contact with computers was on a CDC6400 mainframe. You created the program on punched cards and submitted the card deck with a job ticket via the window to the computer room. Then you waited 2-4 hours for a computer printout on 15-inch wide computer paper with the tear-off perforated margins.

IF your program crashed, the printout was a "core dump". Then you stood in line to see the computer systems analyst who would read the core dump and hopefully try to tell you what when wrong. Three or more tickets later, maybe you got a successful output. If you ran out of tickets you had to go beg the course instructor for extra tickets.

My experience was similar, but not quite the same (and it wasn't quite my first experience with computers, but not far removed). This was as a freshman in college. You would submit the code to the desk on cards and it would be run in about that same time window -- if you timed things right you could get as many as three runs a day of your program. If it failed, we didn't get a core dump, just a cryptic message on that same wide green and white tractor-feed paper. So you can bet we got pretty good at writing error-free code and desk checking our programs before submission to catch logic errors. You also learned not to procrastinate on your assignments, as it was easy to run out of time, plus, you really wanted to avoid the crush of students that hadn't yet learned that lesson. What was interesting was that most people did learn that lesson. At the beginning of the semester, you had no problem getting runs just after an assignment was issued (the two core computer courses accounted for a large fraction of the computer time and their assignment schedules were coordinated) and had to fight to get runs near the deadline. By the end of the semester, it was pretty much the reverse.

 

My first contact with computers was on a CDC6400 mainframe. You created the program on punched cards and submitted the card deck with a job ticket via the window to the computer room. Then you waited 2-4 hours for a computer printout on 15-inch wide computer paper with the tear-off perforated margins.

Reminded me of the CNC based PDP-8 I mentioned. Whenever some arc welding was done in close proximity to the machine, it screwed up the memory, so a teletype and tape reader had to be hauled in close and the memory reloaded, !
Magetic core memory where you could actually see each storage bit !

Compare that to the Raspberry Pi 5 I am using now, , which fits into the palm of ones hand.!!