Anders Sundman: Low, Lower, Lowest level Programming
HTML-код
- Опубликовано: 5 апр 2025
- As embedded C++ developers we often find ourselves in the interface between the abstractions of code and the physics of circuits. In this talk we're going deep embedded to discuss memory layout, linker scripts and micro controller IO. But we won't stop there! We'll explore the electrical engineering basics that every embedded C++ developer should know. Welcome to the bottom of the 'full stack'
Recorded at: www.meetup.com...
This event was kindly hosted by Excillumn, www.excillum.com/
More info about C++ in Sweden and around the world at swedencpp.se 
Наука
Well I was just about to get off to work, but you forced me to get another cup of coffee 😅.
very interesting and informative talk, thanks!
great talk!
It would be nice to dive into multi-core architectures.
As new technologies emerges, have at least two different cpu-s, be it risc, arm, sparc + another one.
Ahhh, he said the thing! 😎 12:48
I don't get it.
@@k6l2t Kyle Reese "It can't be bargained with. It can't be reasoned with. It doesn't feel pity, or remorse, or fear. And it absolutely will not stop, ever, until you are dead."
It's definitely not low level programming. Where are the 1s and 0s ?
(!)
I'm not a professional with embedded systems yet I am familiar with most layers of abstraction. From a C++ language perspective with respect to modern embedded systems, I would say that is fairly low level. It is diving into the entry point into a C++ program by invoking main, setting up or prepping the CPU or system's text and data segments, reset vectors, etc. while also pointing out what to be aware of from the hardware engineering side of things. I can agree that this is fairly low-level programming within the context of a high-level language.
However, I still wouldn't say it's the lowest level. Sure, we are diving into a bit of assembly and sure we are setting up the memory addresses, the stack frame or base pointer, the reset vectors manually, however, it's still relying on the various C++ compilers, linkers, even the operating systems to do a lot of the leg work for us.
If one was to claim that this was the lowest level of C++, then they would be literally writing their own C++ compiler and linker at the assembly or even at the opcode level for a given piece of hardware, architect agnostic of or even without any system calls or kernels from an arbitrary operating system. Yet, most people rarely do this anymore these days. They rely on GCC, Clang, MSVC, and depending on the compiler and linker tool chains, they highly and primarily rely on LLVM pending and in many cases, they also rely on already well-defined filesystems that have already been implemented such as the elf file format or exe executables. People rarely create their own filesystems, and their own virtual tables, memory mappers, schedulers, etc.
So even as this is within modern embedding, there are still many lawyers of abstractions that are still being relied on.
This is just my personal perspective and I'm just a self-taught hobbyist. I've been around computers since at least the mid 80s before most computers even had internal hard drives where they only had a few KB of RAM and enough internal ROM to store a Basic Interpreter. The lowest level of programming agnostic of any programming language including assembly is without a doubt bit banging. If you're not working with the individual bits of each and every instruction within the ISA or the system's OP-Codes, then you are working at some higher level of abstraction. And even this isn't the lowest level of abstraction. When you start to build your own ISA from basic Logic Gates, that's even one lower level, and yet that's not even the lowest level. When you start to build out your system from transistor networks that's even one level lower than pure logic that builds out that logic. Yet that's not even the lowest. When you get into the composition, shape, volume and placement of various materials to make your internal devices such as your transistors, that's even another level of abstraction lower. How far down the rabbit hole do you want to go? Quantum Mechanics? Pure Mathematics and Physical Computations? State Machines? Lambda Calculus? Turing Complete?
Yet, this is why I truly enjoy and appreciate videos like this. The time, work and effort that is put into them for others to observe: Thank You! It was truly enjoyable to learn something within specific subset or subfield of the general field of mathematics, physics, electronics, computers that I am into that I know little about. I'm quite familiar with C/C++ as I have done 3D Graphics - Game Engine - Physics Simulations design, Hardware Emulation, and even dove a little bit into Compiler Design - Language Theory, and even a little into OS-Kernel design. I'm no stranger to C/C++, I have a decent knowledge of Assembly, and a moderate understanding of ISA Design. As for a hobby, I have the following Steam titles in my library: Turing Complete, Hard Chip which are directly related to CPU design not including other titles that have similarities to many topics within computer science either it being software or hardware engineering such as Factorio, Dyson Sphere Program, Mindustry, Satisfactory, Oxygen Not Included and more.
If it's engineering related and is or has the potential in being Turing Complete; I'm game!
Keep up the great work!
Well, low level... But not low enough (No Microcontrollers architecture and assembler for binary operations).
It is a C++ talk. Even assembler embedded in C++ would be a bit off topic because this is about program structure and initialization, [from a compiled C++ perspective] not about optimizing a function.
@@mytech6779 Title says 'lowest level' this video is *clearly NOT* the *lowest level* programming.
I know this is a bit of a brain-mangler for C / C++ devs who come from the "we have an operating system" world... but why not just ditch having a `main()` at all and just call `setup()` and `loop(0)` from your reset_handler? `main()` with it's conventions of `argc` / `argv` and returning a status code just don't make any sense at all on a bare-metal device... so eliminate any confusion that may arise from that by just not having a `main()` at all. Not having a `main()` is a constant reminder that "We're not in Kansas anymore".
This isn't low level - not really. Try writing two apps that share 512B program and 32B RAM on an 8 pin PIC. Try coding a resistance measurement tester covering over 8 orders of magnitude on a platform without a floating point library. You have to write your own. Try 4 bit microcontrollers.
@@lumpyfishgravy inasmuch as that actually defines what low level is, such scenario is becoming increasingly rare and is something we don't have to worry about most of the time
Does any company still manufacture such an MPU? It seems like the ¼ cent saved on the chip would be masked by packaging cost, and any apparent power reduction totally negated by the inefficiency of the extra operations needed to juggle insufficient resources. A product with such specific limited requirements would likely be well served with an ASIC that doesn't need any programming after manufacture.
You should notice this is specifically a presentation centered on C++, not the micro-controller hardware its self.
who uses 4/8-bit microcontroller nowadays? these microcontrollers are more expensive than the 32-bit from other manufacturers
@@mytech6779 Yes, quite so. Today the norm is 32 bit with a few kB RAM and a few 10s of kB flash. And I have embraced it.
CPP lovers here✌️
c++ and em bedded development are absolutely mutually exclusive.
@@markmanning2921 This felt wrong in so many ways. Agree with you 100%
This is not true at all. It is true at all. Hmm, so what. As with any tool, use it wisely. Don't use a sledgehammer where a screwdriver is needed.
So for C++: Don't use all the whistles and bells that modern C++ offers you.
@@monlynx Chuck moore who invented the Forth programming language says if your binary is not at least 100 times smaller than the equiv C whe you code it in forth then you ahve done it wrong.
I for example have coded a ncurses like windowing system in forth in 6 k and ncurses itself is in 600k so this seems to hold true.
Even if you avoid all the language bells and whistles with c++ your resultant binarhy is going to be OVER 100 times larger for being c++. There are two things you dont have enough of in any truely embedded system. Processing power and data (including code) space. Doing embedded things in C++ is *M*O*R*O*N*I*C*.
I have a friend who says that "Developing embedded applications in C is like opening a CAN with a ROCK" But even C is perfereable to c++ (unless its Keil's 8051 C compiler lol).
@@markmanning2921 embedded != embedded. There are embedded systems with 16 Cortex-A72 and 4GB RAM.
Plus C++ code can be done real small.
Regarding Forth: I have not seen any project in my 25 years of embedded programming using Forth.
@@markmanning2921depends on the application.
On esp32, or even the much more constrained atmega328 or even atmega128 etc is perfectly fine with c++.
You can also easily make a wrapper for a function you write in assembly, (or use inline assembly) with c++ for time critical portions of the code.
If the app you are making is dead simple; read a pin and report its state to serial f.ex; its the serial transmission which will be the time limiting factor whether you code in c++, assembly, or probably even with micropython.
(By serial transmission i mean the hardware UART, if you use SPI or bit bang your own "serial interface" then its another matter)
But when your app just gets a little involved, its the regular stuff that often is the issue anyway; bugs.
Not just from code syntax, but also code logic in reference to hardware.
Better tools like c++ over c, in environments where you often dont have (reliable) debuggers is very nice to have.
This isn't low level. Damn kids today.
Having watched the video, it works from hardware boot to main() and considers setting up most of what is usually required. I'm going to call booting a processor up as low as low level __programming__ can get.
Out of curiosity, are you thinking about how to program dynamical systems into other systems? Maybe how to use pen and paper to build and compile a program that you use pen and paper to transport it into the internal language of another dynamical system? Because that would be awesome and I'd read all your papers. [drops the mic and walks away.]
ok, boomer
@@k6l2t Title says *LOWEST LEVEL* this is clearly *NOT* the *lowest level* programming.
Get over yourself.
@@pooyankhosravi5337 Title says *lowest level* this is clearly *NOT* the lowest level.
@@ThunderAppeal lol