OT mcu (STM32F0xx) a JAVA

[Jan Waclawek]

>Ano, otázka není technická, ale spíą pro nějakého sociologa. 

Ano a nie - sociologovia patria do skupiny ludi, ktorych pokladam apriori
za kecalov... ;-)

Ale ten Vas rozbor ma nieco do seba. Takze je mozne, ze ST tou hlaskou
naozaj odpoveda na akusi poziadavku trhu.

>Jazelle, tedy přímé vykonávání bytekódu procesorem mělo nějaký závaľný 
>problém, někde jsem dokonce četl, ľe tento způsob je z principu javy v 
>zásadě nepouľitelný. 

On asi v zasade pouzitelny je, inak by to asi nerobili napriklad Ajile
(dovolim si znova link na uzone:
http://www.mikrozone.sk/pluginy/content/content.php?content.104 ). 

Podla mna bol najzavaznejsi problem Jazelle ten, ze nesplnil ocakavania
ARMu ani jeho zakaznikov - toto aspon podla mna trci z toho clanku na
wikipedii.

Ono to nebola taka 100% nativna hardwarova implementacia bytecodu - podla
toho co citam, to bol skor mikrokodovany interpreter asi 90% bytekodu,
zvysok hodil vynimku co sa riesila softwarovo. Viem si predstavit, ze to v
praktickych aplikaciach znamenalo dost zly pomer cena(kremik obsadeny tym
mikrokodovym rozsirenim)/vykon(zvysenie vykonu oproti plne softwarovemu
JVM); plus z toho wikipedioveho clanku dost trci, ze ARM vytlkal peniaze
kde sa dalo, aj na rozchadzani konkretnych inkarnacii, co znamenalo
pravdepodobne extra prachy ktore museli za licenciu zakaznici platit, a
neprekvapilo by ma, kebyze aj vela chyb, s ktorymi sa museli potom
vysporiadavat.

Ak som dobre pochopil poslednu vetu z kapitoly
http://en.wikipedia.org/wiki/ARM_architecture#Thumb_Execution_Environment_.28ThumbEE.29
, tak uz aj ta minimalna nahrada za Jazelle je mrtva. ARM ma teraz daleko
lepsi zdroj prijmov ako sa trapit s potencialne problematickym softwarom...

wek