HBPF – eBPF in Hardware

Re:HBPF – eBPF in Hardware by AshamedCaptain on Friday April 01, 2022 @10:08AM (#30878208)

First we create a portable bytecode in order to run executable code in a hardware-independent way.

Then we create hardware to run that bytecode.

(No criticism intended to the author, I guess the goal is just to have fun).

[ Parent | on HN ]

Re:HBPF – eBPF in Hardware by yjftsjthsd-h on Friday April 01, 2022 @10:53AM (#30878628)

It's happened before; https://en.m.wikipedia.org/wiki/Java_processor has a whole list of JVM hardware. I suppose lisp machines might also count.

[ Parent | on HN ]

Re:HBPF – eBPF in Hardware by Banana699 on Friday April 01, 2022 @10:12PM (#30885297)

I mean, bytecode that runs on hardware is still hardware-independent, it's the hardware that have to conform to the bytecode's interface not the other way around. If every processor in existence had to accept x86 instruction streams as valid programs, x86 would be a hardware-independent VM.

The issue would be if there are multiple bytecode formats for different hardware.

[ Parent | on HN ]

Re:HBPF – eBPF in Hardware by uluyol on Friday April 01, 2022 @02:56PM (#30881978)

Same thing happens with IO interfaces.

https://lwn.net/Articles/805235/

[ Parent | on HN ]

Re:HBPF – eBPF in Hardware by klysm on Friday April 01, 2022 @02:03PM (#30881311)

I’ve thought about this kind of co-evolution before and it seems to me it always leads to very sub optimal results. The problem is making a better solution is not economically feasible because all the software already exists.

[ Parent | on HN ]