3 ms·
I would say that Java is a more common bytecode than ACPI. Sure, if you just consider desktop or laptops, ACPI will be more common, but feature phones all gener
by lambda 13y ago
I would say that Java is a more common bytecode than ACPI. Sure, if you just consider desktop or laptops, ACPI will be more common, but feature phones all generally include a Java VM, and the baseband on smartphones generally do too. For that matter, SIM cards themselves include a Java Card interpreter, which interprets a stripped down version off JVM bytecode. Your phone may contain two or three different variants of JVM just to make a phone call.
Furthermore, exactly what you consider to be a bytecode vs a machine language can be a bit of an open question. After all, Intel CPUs don't actually execute the x86 instruction set directly, the execute microcode which translates the instruction set into the actual instructions that the CPU executes. So you could say that x86 is the ultimate bytecode. And hey, for a while Mac OS X had PowerPC emulation support, and before that System 7 has 68k emulation support. On the other hand, people have implemented Java in hardware, so today's bytecode may become tomorrow's machine language, and vice versa.
edit: Can whoever downvoted please provide an explanation? This comment is on topic and polite; if you disagree, please explain, as I would be interested to know why. If there's something that's incorrect, a correction would be appreciated.
- Jasper_ 13y agoI don't really care which bytecode is the "most popular". I just thought it would be cool to introduce people to some specified bytecode running inside subsystems that you probably didn't think anything about before.
- cturner 13y agoJasper that was a fabulous start to the morning. A morsel of hacker news on hacker news. Thanks. Would be interested in your thoughts about code generation - I'm writing a VM, playing with ideas. I have wondered at this as an approach to software development: whenever you have a significant task to do, first build a virtual machine. Then create bytecode to satisfy your application. You can have a rich instruction set to meet your needs - writing performant or hardware-oriented features in C, but getting easy access to them through your upstream high-level language. Highly portable, no library dependencies. I'm fine at hand-editing bytecode, but code generation from a high-level language is still a mystery to me. I want to find a notation that gives me enough power to deal with high-level concepts, but for which it is easy to write a compiler to bytecode. Currently options in mind: scheme (lots of resources, but might be too complicated - can tail recursion be done simply? adequate GC?); forth; some subset of C; something fancy with ometa. Or, could I just write scheme functions to output machine code, and build my application logic in macros that on top of that. This bypasses the need for a conventional compiler.
- mtdewcmu 13y agoTo be taken seriously, it will have to target javascript eventually, of course. Perhaps you might as well go there directly and just get it over with?
- noahl 13y agoI like the idea of scheme functions to output machine code. If you know scheme, you're probably already familiar with this, but since you say code generation is a mystery, let me recommend SICP (http://mitpress.mit.edu/sicp/full-text/book/book.html http://mitpress.mit.edu/sicp/full-text/book/book.html).
- cturner 13y agoI scratch around at SICP every few months, and generally get stuck because there's a lot of assumption of mathematics knowledge in there that I don't have. But I started to watch the MIT lectures just last weekend. I'll keep at it, sounds like I'm on the right track. Thanks :)
- lambda 13y agoI don't really think it's that important either, and I thought it was an interesting article that described some bytecodes people might not be familiar with, but you had started your article with "What is the most commonly used bytecode language in the world?" and I was responding to that question. I suspect that it's JVM, due to it's ubiquity in phones, and thought it might be worth pointing out since most people don't know that they have a JVM subset running on their SIM card. We really do have miniature bytecode interpreters running everywhere; and vulnerabilities can lead to security issues that allow your SIM card itself to be rooted[1] [1]: http://www.extremetech.com/computing/161870-the-humble-sim-card-has-finally-been-hacked-billions-of-phones-at-risk-of-data-theft-premium-rate-scams http://www.extremetech.com/computing/161870-the-humble-sim-c...
- rootbear 13y agoIt's fascinating to learn about all of the hidden bytecode implementations scattered about and a bit alarming that some are so complicated. As for most common, when counting up the tally for the JVM, you must include all Blu-ray players too. The interactive menus on a Blu-ray disc are implemented via a java program on the disc.