4 ms·

So a story: I've been a kernel hack since Unix V6, made a living doing it one way or another for over half my life ... learning to think about concurrency, time

So a story: I've been a kernel hack since Unix V6, made a living doing it one way or another for over half my life ... learning to think about concurrency, time, interrupts, race conditions etc is hard, very hard - I got pretty good at it ... but then my career took a diversion, I designed chips for a decade or so, everything is concurrency, at the lowest levels .... after a while I came back to doing kernel stuff and found that with this new background all that hard stuff was trivial and obvious. Mostly you just have to steep your brain in it for long enough

ksml 6y ago
Concurrency is still hard for me, but I do find it getting much easier over the years :) thanks for the story!
rramadass 6y ago
>learning to think about concurrency, time, interrupts, race conditions So what books can you recommend to understand the above subjects? I know of only UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers by Curt Schimmel. >everything is concurrency, at the lowest levels .... after a while I came back to doing kernel stuff and found that with this new background all that hard stuff was trivial and obvious I see a lot of HDL programmers say this. But how exactly do you map the concepts since the very language semantics between HDLs and "Standard" computer languages are different?
- arkj 6y ago
  Consider the simplest RISC execution path, from the software view there is an instruction executing in one cycle but from the hardware view in the same cycle along with the execute there is a different decode and fetch happening.
  - Taniwha 6y ago
    Yes it's thinking about designs partly at that level - but, we don't just design CPUs, it's also understanding synchronization right down to the gate and flop level .... and you need to understand, and deal with, things like metastability ... effectively there exist things that can't always be synchronized, that sometimes fail and you need to deal with them .... and sometimes fail and can't be dealt with, all you can do is to design to minimize those failures .... (done right your design only melts down into a hot buzzy charred mess every century or so - not an issue that software ever needs to deal with)
suifbwish 6y ago
That’s exactly it. It’s the only way to master something. The more varied exposure over time we have to the core ideas of a discipline, the more we come to master the thought process of comprehending it’s limits and possibilities to the extent where we can make it do whatever we like.
febed 6y ago
How did you pivot from kernel programming to designing chips? Did you already have a background in embedded electronics?
- Taniwha 6y ago
  I'm self trained in electronics, I'd started building nubus cards for Mac's and was hired as an architect for new graphics cards ... Started using C as an architectural reference language, from there it was a small step to using verilog instead ... Pretty soon I was building CPUs .... I've always been the hardware guy who understands software, and/or the software guy who understands hardware

ksml 6y ago

Concurrency is still hard for me, but I do find it getting much easier over the years :) thanks for the story!

rramadass 6y ago

>learning to think about concurrency, time, interrupts, race conditions So what books can you recommend to understand the above subjects? I know of only UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers by Curt Schimmel. >everything is concurrency, at the lowest levels .... after a while I came back to doing kernel stuff and found that with this new background all that hard stuff was trivial and obvious I see a lot of HDL programmers say this. But how exactly do you map the concepts since the very language semantics between HDLs and "Standard" computer languages are different?

arkj 6y ago
Consider the simplest RISC execution path, from the software view there is an instruction executing in one cycle but from the hardware view in the same cycle along with the execute there is a different decode and fetch happening.
- Taniwha 6y ago
  Yes it's thinking about designs partly at that level - but, we don't just design CPUs, it's also understanding synchronization right down to the gate and flop level .... and you need to understand, and deal with, things like metastability ... effectively there exist things that can't always be synchronized, that sometimes fail and you need to deal with them .... and sometimes fail and can't be dealt with, all you can do is to design to minimize those failures .... (done right your design only melts down into a hot buzzy charred mess every century or so - not an issue that software ever needs to deal with)

suifbwish 6y ago

That’s exactly it. It’s the only way to master something. The more varied exposure over time we have to the core ideas of a discipline, the more we come to master the thought process of comprehending it’s limits and possibilities to the extent where we can make it do whatever we like.

febed 6y ago

How did you pivot from kernel programming to designing chips? Did you already have a background in embedded electronics?

Taniwha 6y ago
I'm self trained in electronics, I'd started building nubus cards for Mac's and was hired as an architect for new graphics cards ... Started using C as an architectural reference language, from there it was a small step to using verilog instead ... Pretty soon I was building CPUs .... I've always been the hardware guy who understands software, and/or the software guy who understands hardware