Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure this counts as "bare metal" since it runs in a VM. Though doing it this way is probably cheaper then using an FPGA.


I'm not 100% sure but I think it's not running on a VM in the virtualization sense; by VM they probably mean BEAM, which is a VM in the same sense that JVM or python are VMs.


I was hoping they'd actually made a bare-metal BEAM implementation like the Lisp and Forth hardware that people have made in the past. This device looks like it's Erlang-on-BEAM-on-RTEMS, which is undoubtedly a more practical and useful thing, but less intriguing.


Its not really „on RTEMS“, its more side by side. RTEMS is not a layer between the BEAM and te hardware its just helping by providing threads, TCP stack and file access. From a Erlang NIF or port driver (thats what we use to access the outside world in Erlang and Elxir) you have direct access to hardware registers and e.g. CPU interrupts.


If RTEMS is controlling the execution of your code, your running on or in RTEMS.

Direct hardware access isn't really "bare metal" in the same manner as software running in DOS is not bare-metal. direct-hardware access is provided in both.


RTEMS isn't "controlling" the execution of the code, it just supplies implementation for OS-specific utilities (effectively the POSIX API). The BEAM VM code is compiled to machine code and runs directly on the CPU. As peerst explained, if you write your own C code in an Erlang port driver for example, you don't have to use RTEMS at all.


Is there the ability to run multiple OS processes or is the BEAM VM the only thing running after boot?


You can only run one process in RTEMS (hence the name The Real-Time Executive for Multiprocessor Systems), however you can simulate other processes via threads. This is how we run the network stack and Wi-Fi configuration tools among other things.


I've always thought that erlang has a much more natural mapping onto hardware (especially multicore hardware) than lisp.


Yes we boot the BEAM on the hardware.


The distinction between an OS and a language VM is blurry. When the language VM has such robust support for concurrency and IPC, the distinction is, in terms of functionality if not name, pretty much obliterated.


It makes me wonder if anyone has made VMs using the virtualization hardware in modern computers. Nested page tables seem exceptionally useful just as a jumping off point. Maybe the fact that they would still have to use the native instruction set is the limiting factor.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: