Отправлено yes 04 сентября 2001 г. 12:19 В ответ на: Не столь существенно, порядок величины понятен. Кстати, кто-то просил описание байт-кода, ну, и..? :-) отправлено vitA 04 сентября 2001 г. 11:06

да вычисления в виртуальной машине реализованы через стэк (я и раньше это подозревал :) ), то есть тут выигрыш у стэк процессоров

но кроме стэка есть framе и heap - то есть надо иметь индексную адресацию (то есть на пересылках ARM, MIPS, POWERPC и т.п - имеют выигрыш)

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

ну и еще надо учесть как будет в железе реализованы "хранилища" информации - регистровый файл, кэш, память (прошу прощения за нестэтовую терминологию)
то есть если стэк хранить в регистровом файле (я имею ввиду макроячейку) - то возникает вопрос в размере - размер стэка не известен. тут как в преферансе лучше перезаклад, но у него свои минусы - площадь|потребление, да и никто не гарантирует, что хватит (пример такого регистрового файла в SPARC-ах)
а при операциях со стэком во внешней памяти (даже кэшируемой) - наверняка можно успеть 4-8 операций в регистровом файле, что позволяет сэмулировать верхушку стэка в регистрах...

то есть (мое очень необъективное мнение) ARM c аппаратным декодером джавы может не уступать стэк процессору с более высокой тактовой, когда они работают на одинаковой памяти при исполнении байт-кода

--------------

все - пора работать :)

• да, но ARM c аппаратным декодером джавы - это уже совсем другая песня, на сотни k.gate, я думаю — vitA   (04.09.2001 13:17, пустое)
  • у нас с THUMB декодером получилось 30К — yes   (05.09.2001 12:50, 52 байт)
    • Т.е. в 10К400 - десяток - другой таких можно вставить! — vitA   (05.09.2001 14:07, 60 байт)