EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: obiwanjacobi on March 07, 2016, 07:34:12 am
-
Lately I have been reading/watching some on processor design. I had this idea to have a (soft)core execute the byte code (either MSIL or Java) directly in the processor. Now I haven't researched this at all - it's just a wild idea and I am sure you guys will spank it down if it is flawed :P
I could see embedded applications -probably not too time critical- that run on easy to develop code and existing IDE support... Could be the next step after Arduino... dunno. Of course you would need all new libraries that replace any dependency on any OS...
(Patent pending :-DD )
-
http://electronicdesign.com/embedded/java-core-permits-direct-java-byte-code-execution (http://electronicdesign.com/embedded/java-core-permits-direct-java-byte-code-execution)
-
it's just a wild idea and I am sure you guys will spank it down if it is flawed :P
There was Jazelle mode for ARM processor. It was a complete flop and it is no longer available in new chips.
It is doable, but stupid because of dependencies on the OS and hardware-specific stuff. If bytecode asks to open a file, you have to do that, even if does not make much sense in FPGA.
In case of Jazelle, it would bail out of all those hard to implement instruction and pass control to normal ARM code.
-
Don't know about Java, but I don't think there is an 'open file' instruction in MSIL...? To open a file is simply a function call. So you need hardware specific libraries - that may not even have a file system...
http://electronicdesign.com/embedded/java-core-permits-direct-java-byte-code-execution (http://electronicdesign.com/embedded/java-core-permits-direct-java-byte-code-execution)
"We ran a Java-accelerated ARM9 core on an instruction set simulator and determined a Java performance of 5.5 CaffeineMarks/MHz."
:-DD
-
There are chips that talk FORTH directly. They are mainly for space applications, the Philae lander had them. There should be civilian chips on the market but I'm not sure which ones.
-
Interesting, clearly I'd misinterpreted it, and I don't particularly follow the ins and outs of Android development much these days, but I'd always assumed that the very reason Android is biased towards Java for development was because of the availability of Jazelle/ThumbEE on ARM applications processors. Certainly in the first Android releases, Java was the only way to develop code, there was no native development kit.
-
Lately I have been reading/watching some on processor design. I had this idea to have a (soft)core execute the byte code (either MSIL or Java) directly in the processor. Now I haven't researched this at all - it's just a wild idea and I am sure you guys will spank it down if it is flawed :P
I could see embedded applications -probably not too time critical- that run on easy to develop code and existing IDE support... Could be the next step after Arduino... dunno. Of course you would need all new libraries that replace any dependency on any OS...
(Patent pending :-DD )
In the general sense you can have an instruction set in the hardware at many levels be it RISC, CISC etc. and this has been done in many variants in the past so I am not sure your patent will hold. It's a fun idea though although the general purpose nature of a generic instruction set might make that a more flexible solution in the end.
In the java world there seems to be a tend away from executing in a pure JVM to actually executing native code by incorporating a pre-execution translation step, recently this has taken the form of the hot spot compiler than natively optimised parts of the execution but the trend seems towards a compile step and then native code.
-
Lately I have been reading/watching some on processor design. I had this idea to have a (soft)core execute the byte code (either MSIL or Java) directly in the processor. Now I haven't researched this at all - it's just a wild idea and I am sure you guys will spank it down if it is flawed :P
I could see embedded applications -probably not too time critical- that run on easy to develop code and existing IDE support... Could be the next step after Arduino... dunno. Of course you would need all new libraries that replace any dependency on any OS...
(Patent pending :-DD )
In the general sense you can have an instruction set in the hardware at many levels be it RISC, CISC etc. and this has been done in many variants in the past so I am not sure your patent will hold. It's a fun idea though although the general purpose nature of a generic instruction set might make that a more flexible solution in the end.
In the java world there seems to be a tend away from executing in a pure JVM to actually executing native code by incorporating a pre-execution translation step, recently this has taken the form of the hot spot compiler than natively optimised parts of the execution but the trend seems towards a compile step and then native code.
That trend has been evident since the mid-1980s, when L Peter Deutch created the first JIT environment (for Smalltalk).
Basic principle: for a custom CPU to be worth considering, it has to be at least 100* better than a general purpose CPU. That might change if the progress in semiconductor technology slows due to hitting fundamental physical limits.
-
There is at least JOP:
http://www.jopdesign.com/ (http://www.jopdesign.com/)
http://opencores.org/project,jop (http://opencores.org/project,jop)
-
Found this for the MSIL...
https://www.phoenixcontact-software.com/en/iec-61131-control/runtime-systems/proconos-eclr (https://www.phoenixcontact-software.com/en/iec-61131-control/runtime-systems/proconos-eclr)