(Untitled)

[muchandr]

Какая прелесть. ARM тихой сапой добавил явовские байткоды в качестве еще одной ISA. (у них уже и так было две) Поскольку ARM просто везде, можно с уверенностью говорить, что никакой Явовской виртуальной машины вне пределов совсем "взрослых" писюков и рабочих станций уже нет - нелепая архитектура явовской машины канонизорована "в железе"! Фу

Comments

[potan]

Виртовцы сжимали AST Оберона. На мой взгляд - фигня вышла.
JITу сложные адресации не нужны. Он переводит стековый код в нормальный трехадресный, а потом его компилирует.
Аппаратная Java хороша для систем с маленькой памятью. Каковыми являются все встраиваемые системы :-).

[muchandr]

Преимущества по скорости доступа последовательных данных - тоже артефакт архитектуры DRAM. В самом упрощенном виде, ты сначала долго и муторно инициализируешь, какой тебе нужен ряд. Потом колонку. На самом деле в последнее время все еще гораздо мутнее, но общая идея такова - крохотные кондеры в традиционном DRAM быстрее практически не становятся. Посему мы стараемся кучу похожих трансакций аггрегировать, а потом ту часть, которая у них общая, делать зараз. Скажем элементарный SRAM такими свойствами не обладает, ему совсем не обязателен хитрожопый контроллер. Пиши себе, куда хочешь.

[9000]

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

Сценарий 1: Мы читаем N независимых бит. Чтобы это проделать, нам надо загнать N независимых адресов в контроллер памяти.

Сценарий 2: Мы читаем N бит, адреса которых получаются из одного числа применением какой-то простой функции (например, "прибавить номер бита"). Теперь в контроллер памяти надо загнать только одно число + сослаться на функцию (если она не имплицитна).

Мне кажется, что сценарий 1 требует больше времени, чем 2. Где я неправ?

[muchandr]

Прав. А что тебе мешает писать свои битстринги произвольной длины в память последовательно? Пиши на здоровье.

[9000]

Со стрингами длиной сильно больше N всё просто. Жаба начинает душить при данных длиной сильно меньше N: хочется загрузить их в один такт побольше и устроить MMX ;) Но это, наверное, ошибка мышления: тут компилятор должен распараллелить доступ нескольких команд или ниток.

[muchandr]

Точно ошибка мышления :)

С чего ты взял, что у адреса должна быть фиксированная длина N? Он тоже может быть переменным. У тебе нету больше никакой параллельной шины длиной N, а есть N совершенно независимых серийных интерфейсов. Сколько-то из них не нужны - не пользуйся. Именно поэтому серийные интерфейсы типа PCI-e так сильно пошустрели - синхронизировать сигнал в уйме параллельных проводов больше не надо, для каждого бита свой собтвенный умный контроллер.

В контексте памяти это дело пионировал Rambus. Сначала сделай грамотную передачу одного бита с однобитным оффсетом, а потом мультиплексай себе на здоровье, сколько надо. Таким образом, число N зашито не на уровне архитектуры, а лишь ее какой-то конкретной имплементации.

[9000]

Пожалуй.
Хотя тут возникает проблема синхронизации всё равно: для многобитного значения мне надо дождаться прибытия всех бит. Но это нетрудно, и это не большая плата за произвольность числа бит. Для всяких потоковых алгоритмов, типа аудио, видео и крипто, это прямой бонус.

[muchandr]

Синхронизировать гораздо легче в логике, чем в толпе проводов.

[muchandr]

Потом тот факт, что в самом языке нет НИЧЕГО, был сознательным идеологическим выбором для С. Как оказалось, правильным. Именно отсустствие необходимости таскать за собой огромную стандартную библиотеку позволило языку пролезть везде.

[muchandr]

И как JIT этого добивается? Правильно, сначала из байткодов восстанавливается AST :)

Что значит "нормальный трехадресный"? Это нормально при наличии 32-битного опкода, примерно 32 регистров общего назначения и сравнительно медленной памяти. Кстати, вторая ISA ARM, Thumb, 16-битная двухадресная и добавлена именно ради возможности получения более компактного кода на встраемывых системах, хотя в целом ARM 32-битная архитектура.

Зачем добавили аппаратную Явы СЕЙЧАС, очевидно. Технически грамотнее было бы ехать с обратной стороны - придумать стандартное встроенное железо. (Коим сейчас де-факто является как раз АRМ)

[potan]

JIT компилятор как бы исполняет код, помещая в стек номера регистров вместо данных. Соотвественно операции над верхушкой стека порождают команду трехадресной машины с неограниченным количеством регистров (трехадресный код) и в стек записывается номер свободного регистра. А потом решается классическая компиляторская задача распределения регистров, что бы отмапить виртуальную трехадресную машину в реальную.

[muchandr]

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

[potan]

Я видел реальные компиляторы - заглядывал в исходники gcc. Реализацию JIT не смотрел, но что-то про нее читал.
"Операции на стеке" выполняются на этапе компиляции - потом стек для вычислений не нужен.
Компиляция дорога, но выполняется только один раз. В этом то и прелесть JIT.

[muchandr]

Ну ОК. А какие в этом подходе преимущества по сравнению с декомпиляцией в AST?

[potan]

IMHO, он проще.
Более того, все декомпиляторы (не Java), которые я видел, бинарный код сначала переводили в трехадресный, а потом после упрощающих преобразований, транслировали в язык высокого уровня.