Слышал что сан разработал абсолютно хардовый интерпретатор своей java... А на каком принципе он основан? Поделитесь интересной ининформацией по этому вопросу. Как вообще такое возможно ... Да ещё с бланкоми регистров ... Если все переменные находились в памяти а не в регистрах то грош цена этому интерпретатору...
_evil, никогда не слышал, но ведь и не следил чем это принципиально отличается от части jvm на smartcard?
Мне кажется такому интерпретатору в любом случае грош цена. Использовать n-ное количество регистров для верхушки стека по-моему никакая не новость и вроде даже интел это со времен царя гороха применяли, как и нелинейное исполнение. Скорей всего ты имеешь в виду picoJava-II, которая выпущена не была. Есть также jop https://www.jopdesign.com/perf.jsp , который вроде как таки был выпущен. Я правда так и не понял зачем там в списке бордов есть плата с hitachi h8 и sparc'ом. Но на сайте утверждается, что Altera и Xilinx таки выпустили чипы с этим ЖОПом. --- Сообщение объединено, 27 апр 2019 --- Там типа без jit, напрямую исполняется.
JOp впечатляет по графикам ... И почему его свернули если он такой хороший? ... Как так массив регистров на вершине стека ? Может ты сказать хотел кесш - но он будет по медленнее ... И если ты говоришь регистры то почему обращение к обычным регистрам намного быстрее чем к переменным в вершине стека?
Ну да, типа кеш, который может сдвигаться весь за один или около того тактов. А какая область применения у процессора, который построил один австриец? При том, что ява без проблем существует и без собственного чипа, и ей это совсем не мешает.
нет особо принципиальных проблем компилить байт-код джавы в нативный код эхэд-оф-тайм вместо джита... есть граальвм, который умеет и то и то...
Вместо стека регистров не может быть - что если сделать SP+=20 что оно 20 регистров в память запишет? Как понимать ?
Наибольшее число обращений будет в пределах определенного окна относительно верхушки стека. Ее можно реализовать аппаратно, а все, что в окно не входит, адресовать через память. За счет этого весь профит, обращение к регистру происходит гораздо быстрей, чем к по сути внешнему устройству ОЗУ на системной шине. Другое дело, что современные процессоры устроены не так, как выглядит их программная модель. Там есть и кэш и нелинейное исполнение по готовности операндов и предикция и прочие оптимизации. Что может противопоставить архитектура, разработанная любителем, усилиям целой корпорации за несколько десятилетий? В чем принципиальный выигрыш от использования программной модели java в реальном процессоре? Если даже Sun на эту затею смотрят с недоверием.
Было бы интересно узнать как они организовали сборщик мусора - схемно или программно ? Я всегда удивлялся подобным штукам - например сохранение значений регистров при переключении задач в защищённом режиме - как они это сделали ? последовательное сохранение каждого регистра (это ж медленно) или параллельная запись (что-то много дорожек в проце).
