Уважаемые сограждане, подскажите пожалуйста, существует ли реализация
java-машины на ядре ARM7TDMI ?

Сообщение отредактировал mihask - Jan 16 2007, 11:46

На сколько я знаю - нет.
Но существуют ARM процессоры (кажется ARM10/ARM11), со встроенной аппаратной поддержкой JAVA и для их задействования нужен соответствующий софт. Софт этот - платформозависимый, и покупатьего надо типа у производителя чипа.
Сами процессоры содержат в маркировке букву J (типа ARM10J).

В PDA (опять же - насколько я знаю), используются частные решения по договоренности, то-ли с Sun, то-ли с производителем ОС. Что-то вроде того.

Коммерческие реализации для ARM7TDMI есть, но особой популярности они, похоже, не получили.

Технология от ARM называется Jazele. Самое популярное ядро с jazelle - ARM926EJ-S, встречается у многих производителей. Но софт, как уже сказал amw, нужно покупать у ARM.

Я не большой знаток java. Прямо скажем никакой я не знаток java.
Поэтому не пинайте строго:

А вот как вы думаете почему java не распространено на всяких там ARM? Ведь и в 51-ый даллас даже затолкали, и надо полагать не тормозит этот процессор вместе с javой. Потому как если 51-ый еще тормознее будет, то нафиг кому он нужен.

И к тому же исходники java открывают, может теперь проще будет переносить java-машину на разные мелкие процы?

Ведь этоже программистам удобней будет - один и тотже код на разных процах пользовать можно будет, и при необходимости один и тот же программист может писать и для контроллера, и верхний
уровень этого контроллера на компе(ну тут конечно вилами по воде ).

Я в чем то не прав или я во всем не прав ?

Для АRM достаточно Java VM хотя бы потому, что он применяется в КПК ( ARM9).
Бегло пролистнул интернет и сразу попалась одна из ссылок по затронутому вопросу.

http://www.rtjcom.com/ ( ARM7 там представлен)

Выдержка.
Specially optimized to run on the embedded systems with limited memory resources. On average the simpleRTJ will not require more than 18-24KB of code space to run.
Designed to run as a stand-alone miniature Java operating system. No other RTOS is required to be present in the memory. ...

P.S. Думаю, если озадачиться данным вопросом, то материала можно найти достаточно

Вот попалась еще ссылочка, открытый код:
http://www.harbaum.org/till/nanovm/

Ну то что java VM для ARM7 имеется я понял.

У меня даже лучше ссылка есть http://java-virtual-machine.net

Но вот интересно, почему эта технология не распространена также как СИ, C++, RTOSы ?
Я имею ввиду не КПК и сотовые телефоны, а промышленную электроннику построенную
на ARM7 например и прочих мелких процессорах. Ведь java довольно популярен на
писюковой платформе и помоему не только в сетевых приложениях.

А вот еще вопрос - Открытие исходников java не может повлиять на то, что java машины теперь
будут более активно портироваться на разные мелкие процы ?

И вообще что дает открытие исходников java ?

Вкратце.

Java, в общем случае, состоит из двух больших частей.

1. Язык программирования Java.
( можно непосредственно компилировать в коды целевого процессора, с поддержкой
в рантайме исполнительной среды. но тогда этот подход, почти не отличается от Си, С++, RTOS)
2. Виртуальная машина Java (JVM), в байт-коды( стековой машины) которой компилит Java язык.
При исполнении код JVM преобразуется, часто с профилированием,
в родные коды исполнительной платформы или непосредственно исполняется.

Если с первым более менее ясно,
то ко второму пункту для использования в контроллерах есть вопросы и соответственно
решения при выборе схемы работы с контроллером.

Реализация JVM на стороне контроллера без профилировщика снижает скорость работы
программы, что не всегда допустимо.
Добавление профилировщика - утяжеляет систему по требуемым ресурсам и вносит
недетерминизм в работу системы.

Кроме того, т.к большая часть информации уже потеряна в байт-коде исполняемой
программы, то задача профилирования в регистровую архитектуру конкретного
контроллера задача нетривиальная.




Портов JVM и так предостаточно и нет особой сложности портировать непосредственное
исполнение байт-кода, важнее открытие достижений в технологии профилирования байт-кода

P.S. При всем сказанном у Java, все же, есть шансы потеснить C, C++, на рынке разработки
приложений для контроллеров.






Было одно время, в качестве пробы, отработал nanovm проект под IAR-ом для AVR.
Вопросы по данному подходу тоже остались

Большое спасибо за ответ
Теперь сам немного почитаю попросвещаюсь про профилирование и все такое

Я сам не есть специалист в Java, и потому выскажусь почему это не нужно лично мне. Первостепенной целью при разработке концепции Java ставилось получение системы требующей минимальных (в идеале вообще не требующей) изменений при переноске кода с одной ОС на другую, и с одной архитектуры на другую. Т.е. титанический ( ) труд "писальщиков-архитекторов" J-машин выливается в простоту работы (и соответственно скорость обучения) рядовых Java программистов. Но с точки зрения ресурсов Java это "софтовый" проц в вашем "железном" проце со всеми вытекающими. Понятно, что для обеспечения переносимости от Java отрезали все что можно отрезать у процессора. Это, по сути, стековая ЭВМ с минимумом регистров (4 минимум кажеЦЦо: счетчик команд, регистр доступа к локальным переменным, указатель на стек операндов и последний (сам не знаю чо это ) указатель на окружение времени выполнения). Стековая ЭВМ это медлительность в замен компактности ("короткости") кода (в смысле в байтах). Кажется, так же все обстоит и в Fort системах, очень близких по духу Java, но я о них токо слышал. То же как будет распределена эта машина внутри реального ("железного") проца это вопрос к разработчику виртуальной машины и напрямую зависеть от его дара и потраченного времени. Т.е. я хочу сказать что разброс эффективности будет огромный. Вобщем применение такого дива в embedded довольно сомнительно (особенно если вам придется самому писать машину, а потом садить за написание программ зеленых Java-кодеров хотящих в провинции 1500$ в месяц) а уж в DSP системах (где ресурсы вплотную определяют время обработки, а следовательно и круг решаемых задач) и вообще следует избегать применения Java.
Вобщем-то все, с удовольствием прочту критику своих мыслей.

P.S.: Интересно реализовать Java машину на ПЛИС, тогда там все будет родное и железное . Кстати, есть же готовые Java-процы. Forth и Lisp-машины в кремнии тоже кстати имеюЦЦо.

Ну не совсем софтовый! См здесь: http://www.arm.com/pdfs/JazelleWhitePaper.pdf.

В кратце, в ядрах J кроме арм и тумб режимов добавился еще и жаба режим работы. 134 жаба байт-кода выполняются непосредствнно процессором, остальное эмулируется программно в обработчике исключения нейзвестной команды. Регистры виртуального процессора и 4 слова из вершины его стека отображаются на обычный арм регистровый файл. соответственно скорость должна быть хорошей. При этом и реакция на прерывания ядра не ухудшилась, поскольку жабовский байт код может быть прерван.

Касаемо http://www.rtjcom.com/ - очень понравилось, что есть отладчик жабовских приложений, в том числе и многопоточных. Вот песня, когда один поток трассируешь, другой приостановил, а остальные жужжат себе (в смысле квакают, жаба ведь ), работают!

Верно, при условии выполнения Java программы без JIT в регистровой архитектуре.
Форт хоть как и Java используют понятие стековой машины ( также как и Net ),
но все же имеют большие различия.
Стековая машина в Jave вторична, по отношению к языку.( это среда исполнения программ).
В Форте же на ней построен весь язык и все ресурсы ее доступны из языка.
Ваше мнение об медлительности Java ошибочно, что прекрасно демонстрируют
Sun-е JVM. C Фортом дело обстоит примерно также. ( хорошая оптимизация присутствует
в комерческих Форт средах). Зачастую использование и поддержка Форт средств держится
на группах энтузиастов и отдельных людей использующих данный язык.



Вроде уже есть Например JOB ( или JOP ) .

Я вот в свое время проходил язык Форт и писал на нем программы и котегорически не согласен с тем что он медленный так как он изначально был разработан для применения в системах реального времени в часности Американских системах управления ракетами и в нем повышение производительности произходит за счет уменьшения времени доступа исходным данным различных операций так как все лежит в одном месте в стеке ! но писать такие программы такая попа !