One key frustration is it’s typically not possible to have an arm distribution that boots across most arm boards, because they have incompatible boot loaders. Ie you have a raspberry pi image and a banana pi image and an orange pi image and the rock pi S image that are all different from each other. There have been some attempts at UEFI on arm that would address this, but it’s nowhere near as consistent or compatible as on the x86 platform side.
They decided that instead of having an Android runtime on top of ChromeOS they would port the ChromeOS desktop features to Android. A Googlebook boots Android.
A single board computer contains an application processor, not a microcontroller. They have very different design goals.
A microcontroller is a type of processor that offers very fast startup, predictable timing and direct access to hardware peripherals. In contrast to application processors that are intended to run an operating system, a microcontroller will not have OoO execution, multiple tiers memory (eg cache and dram). Usually they also lack an mmu and multiple privilege levels of execution (although that seems more common on riscv microcontrollers). All this means microcontrollers aren’t designed to run Linux (even if someone does figure out how to do that) or clock in the gigahertz, but instead provide very predictable low latency execution required for managing real time systems. For example they might need to operate a set of mosfets with microsecond accuracy to efficiently and safely control a motor.
Ah it looks like the editor does, but the run screen does not. My guess would be since it’s emulating dos programs, probably the keyboard should always be visible.
in the context of CPU performance / architechture `IPC` pretty much always means "Instructions per clock". That's a measure of the internal parallelism a given CPU core is achieving. Most of the time code is not able to get very close to the theoretical maximums a core can achieve for very long, so the numbers the OP is quoting are incredibly impressive.
I believe most of the 8bit microcontrollers from this era have no good optimizing compilers that get close to what competent practitioners achieve with assembly. I think it has to do with having complex addressing modes making the C stack fairly inefficient.
You are arguing against a very well known phenomenon. Technical people often avoid getting promoted to management precisely because they love doing the thing themselves. Despite the higher potential for impact in a management position, losing the detailed view of a practitioner is a real loss. This phenomenon is less obvious in big tech because there are so many people who really wanted to be managers the whole time, but had to be engineers first or never really cared about the work, but want a promotion for the better pay.
You either replied to the wrong comment or didn’t and proved my point exactly: some people like the technical low level approach, others prefer the higher level architectural work.
There’s space for both and there’s a need for both.
reply