Something like dealing with synchronization and locking instead of just “and then we send this command to the mapper, and a lot of executors work in parallel”?
No, I was comfortable with locking and the sort of stuff you’ll routinely see in high level languages where they lock away the complexity behind abstraction.
I’m talking about the “fun” of physical cores which few sane programmers touch.
Though most programmers outside of chip companies can’t touch those levels nowdays since even assembly is treated like a high-level language.
I had something of a similar experience writing software for a company that designed its own chips. I was writing in C, and occasionally, the programs had errors that I couldn’t debug. At that point I’d dive into the Verilog for the chip and see how it was all wired up. And often that would be the problem.
It’s a commonplace that the thing that determines the meaning of a computer program is itself a computer program. But it’s still weird to get bitten by that fact when you’re writing C.
The chip is a program, which determines the meaning of the machine code, which is a program produced by the C compiler, which is a program interpreting the program I’m writing. And whether you look at the chip as a compiled version of the verilog (compiled by another program, with silicon as the target) or as a logical program which you’re proving things about in your head, or as a program being interpreted by a simulator, that’s a lot of turtles.....
Something like dealing with synchronization and locking instead of just “and then we send this command to the mapper, and a lot of executors work in parallel”?
No, I was comfortable with locking and the sort of stuff you’ll routinely see in high level languages where they lock away the complexity behind abstraction.
I’m talking about the “fun” of physical cores which few sane programmers touch.
Though most programmers outside of chip companies can’t touch those levels nowdays since even assembly is treated like a high-level language.
http://blog.erratasec.com/2015/03/x86-is-high-level-language.html#.VvQhiOaAnSg
I had something of a similar experience writing software for a company that designed its own chips. I was writing in C, and occasionally, the programs had errors that I couldn’t debug. At that point I’d dive into the Verilog for the chip and see how it was all wired up. And often that would be the problem.
It’s a commonplace that the thing that determines the meaning of a computer program is itself a computer program. But it’s still weird to get bitten by that fact when you’re writing C.
The chip is a program, which determines the meaning of the machine code, which is a program produced by the C compiler, which is a program interpreting the program I’m writing. And whether you look at the chip as a compiled version of the verilog (compiled by another program, with silicon as the target) or as a logical program which you’re proving things about in your head, or as a program being interpreted by a simulator, that’s a lot of turtles.....