Live data from Hacker News

Ask HN: What should a systems/low-level software engineer know?

news.ycombinator.com

141–150 of 231 posts

Re: Ask HN: What should a systems/low-level software engineer know?

#141

One important thing for an embedded engineer (just like any software engineer!) to know is how to select an appropriate solution for a given problem. This includes both hardware and software, and do it yourself vs off the shelf. I think it can be summed up with some questions to ask at different points in a project: - Should I use a microcontroller or a processor? If a microcontroller should I use a simple 8 bit or m…

In your opinion is 8-bit even a realistic choice anymore? Many ARM CPUs offer way more bang for your buck nowadays (unless i'm looking in the wrong place).

Depends on your cost/power/space budget. There's plenty of new 8-bit work being done today.

Re: Ask HN: What should a systems/low-level software engineer know?

#142
post #85

Earlier quoted context omitted.

What. What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? Edit: "But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow neve…

> What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? MISRA C standards, popular in embedded projects especially automotive, ban the use of memory management altogether. The whole point of RAII is that the compiler manages it for you as far as it can. This is impossible in C because you have to do it manually. You might end up writing malloc() at the to…

Note that they ban the use of dynamic allocation at run-time except via the stack, but that you are still allowed to allocate from the heap as long as that heap allocation is static for the life of the system. This avoids a whole host of problems related to heap exhaustion that result from allocation timing causing heap fragmentation.

Re: Ask HN: What should a systems/low-level software engineer know?

#143

A bit on the more unusual side, one thing my son and I found very instructive on "lower level" concepts is the fact that within PICO-8, which is already a very user friendly high-level environment, you can use peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses. Literally all the capabilities that PICO-8 gives you, it exposes memory for it and explains the conventions it uses…

> peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses

Surprised that this hasn't been exploited to build a C compiler targeting the platform. (Unless I needed to Google something other than "pico-8 C compiler"...)

Re: Ask HN: What should a systems/low-level software engineer know?

#145
post #143

A bit on the more unusual side, one thing my son and I found very instructive on "lower level" concepts is the fact that within PICO-8, which is already a very user friendly high-level environment, you can use peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses. Literally all the capabilities that PICO-8 gives you, it exposes memory for it and explains the conventions it uses…

> peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses Surprised that this hasn't been exploited to build a C compiler targeting the platform. (Unless I needed to Google something other than "pico-8 C compiler"...)

The only thing I can imagine that would be good for is learning how to write a C compiler :)

Re: Ask HN: What should a systems/low-level software engineer know?

#146

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

I agree with you on everything except regular expressions. I would hope a system programmer would move beyond regular expressions towards safe, linear complexity binary parsers.

And I would also add fuzz-testing to your list.

Re: Ask HN: What should a systems/low-level software engineer know?

#147
Some Ulrich Drepper papers:

- on memory access/caches/memory hierarchy: https://www.akkadia.org/drepper/cpumemory.pdf

- on DSO: https://www.akkadia.org/drepper/dsohowto.pdf

- Agner Fog on CPU optimization, latencies, vectors etc: https://www.agner.org/optimize/

Re: Ask HN: What should a systems/low-level software engineer know?

#148

One important thing for an embedded engineer (just like any software engineer!) to know is how to select an appropriate solution for a given problem. This includes both hardware and software, and do it yourself vs off the shelf. I think it can be summed up with some questions to ask at different points in a project: - Should I use a microcontroller or a processor? If a microcontroller should I use a simple 8 bit or m…

In your opinion is 8-bit even a realistic choice anymore? Many ARM CPUs offer way more bang for your buck nowadays (unless i'm looking in the wrong place).

Yes 8 bit is absolutely a good choice. ARM comes in less than a dollar for the cortex m0 core (maybe others now?) but sometimes that is more than you need in both size and capabilities.

Also sometimes you may have existing expertise, tooling, or firmware already for a processor such as a PIC, AVR, or STM8, so why reinvent?

Some examples may be things like a custom serial to input/output expander, small motor controller, power controller, data logger, or other small and simple machines.

Re: Ask HN: What should a systems/low-level software engineer know?

#149

Embedded programing pay sucks compared to the web. I wouldn't do it. Just look at the number of web jobs vs system programmer jobs.

I've done embedded a few times in my career (usually higher level, embedded Linux) though I also did some stuff with PIC microcontrollers for a bit. The pay sucks, but it is much more enjoyable work than web development. There's a lot less BS to deal with.

I feel there is the BS there too. You need to get board support packages. Sometimes the memory map is wrong. If you can get board up it might be a timing issue and you have to solder onto the Trace etc.
Post reply on HN