Thursday, 28 December 2017

Erlang DBX - An Idea Lost in Oblivion

When can I see BEAM (Erlang VM) specification book is what I am thinking right now. Currently we have Java Virtual Machine Specification and Java Language Specification for Java 8 books available. Having a nice book on the internals of the BEAM would be great.

BEAM is a register based VM and Hotspot is a stack based VM. Erlang code is converted into Core Erlang and then to BEAM bytecode by the Erlang compiler. I had this idea of implementing BEAM and the ERTS on a circuit as in Jezelle DBX for ARM which does Java direct bytecode execution in the hardware. It was mainly used during the Java ME era. I don't think this is used much these days.

My idea (brainstorming) was to have the entire ERTS on a chip. So the board can be considered analogous to Intel 8086 chip which has a CPU, memory unit, bus, bridges and all that mechanism. To have ERTS, it should have similar system. There will a CPU which executes the BEAM bytecode as opposed to x86 assembly instruction. Then we need to think about instruction sets timing, clock speeds. The registers required. Having the ERTS entirely on a physical circuit would make things more rigid as in how do we update things. So how about having parts in microcode and have a translation layer? The chip should be energy efficient, should outperform existing hardware, else we will have another Lisp Machine. We would require some sort of network on the chip if we are to have multiple Erlang VM on the same chip, which can communicate with each other. Should we think about security aspects of VM communication? What comes in mind is the QNX's Qnet protocol which allows the QNX Neutrino micro-kernel to transparently distribute and communicate over trusted devices.

Thinking about scheduler and job scheduling, BEAM has a master scheduler and they keeps changing. So should the CPUs be symmetric or is it better to have an asymmetric cores as in Cell BE microprocessor? If we use CISC, then the circuitry is going to be complex which requires more energy and produces more heat. So RISC then? Then we have the whole can of worms that modern CPUs comes with like out-of-bound execution, caching, pipelining, branch prediction and I have no much idea how to approach that in case of ERTS. Mostly we have to come up with our on mechanism as these are not part of the ERTS. The BEAM can have at most two copies of a module at the same time. But that does not count as caching.

From a tooling perspective, I know I can use VHDL and Simulink, OrCAD etc., but since I am not really a hardware oriented person and due to the lack of time and change in priorities, I just put this idea to rest. So my Erlang DBX idea is now lost in oblivion. Why would one need such a chip? Well Google has TPUs (Tensor Processing Units), so I thought having some dedicated Erlang chip is a cool thing to do.

As for the book, The Erlang Runtime System was cancelled, however an online copy is available.

No comments:

Post a Comment