Я слышал про аппаратные JAVA-процессоры (вроде бы стековые), но не могу понять почему они так называются и как идеология
высокоуровневого языка повлияла на особенности аппаратной реализации этого процессора.
Для Паскаля или Си процессор другим бы был что ли? )

Java использует стековую модель вычислений. Процессор с регистровой архитектурой вынужден тратить дополнительные такты на эмуляцию такой модели. Можно посмотреть на расширение Jazelle, которое делали для ARM именно для ускорения JVM. Паскаль и Си напрямую не предполагают какую-то конкретную модель вычислений, регистры процессора участвуют там довольно опосредованно. Фактически, они предполагают наличие переменных в памяти, а вовсе не какие-то регистры. Поэтому сделать процессор для Си или Паскаля можно только при учете той модели кода, которую они используют, а не синтаксиса языка.

Хищник, кончай опять дурить людей. C-переводится в язык ассемблера стандартным способом. Подразумевается некоторый достаточно универсальный и почти всеми понимаемый. Для проверки, надо взять пару компиляторов и посмотреть, что они выдадут с ключом -s.

Имеется в виду Java-процессор/JVM?
Интересно то, что при рекламном описании JVM не акцентируется внимание на стековой модели вычислений.
Только при упоминании об аппаратных Java-процессорах я первый раз услышал про стековую модель.

Неужели же язык Си жестко привязан к определенному промежуточному представлению кода? Какому, если не секрет? Стековое, тройки, четверки? А какая конкретно конструкция Си заставляет пользоваться только этим промежуточным представлением? Что-то мне подсказывает, что проверка "пары компиляторов" не позволит однозначно ответить на этот вопрос. Скорее она позволит убедиться, что для определенной группы компиляторов было эффективным/модным/удобным определенное представление кода.

В .net используется такой Microsoft Intermediate Language (MSIL). Если почитать его спецификацию, то среди его команд имеются... dup drop и прочее! Только арифметические действия названы по мнемоникам - add, sub и т.п., да store использует порядок операндов, противоположный требуемому словом !. А так MSIL - это стековая машина плюс сборка мусора плюс метаданные. Другое дело, что потом добавляется back-end, который переводит команды этого промежуточного представления в код, оптимизированный для конкретной архитектуры.

Да. См. выше.

Что "да"? К какому - к стековому? А в тройки компилировать нельзя? А для трехадресной ортогональной архитектуры компилировать в четверки не будем из вредности - все через бутылочное горлышко стека?
Навскидку, по ключевым словам "язык Си промежуточное представление" нашлось, к примеру, вот такое:
http://www.optimitech.com/docs/006.pdf
Жду комментариев.

Для тех, "кто на бронепоезде" повторяю: промежуточным представлением C-программ является универсальный упрощенный язык ассемблера.

Ответ из серии: "какие бывают станки? Фрезерные, токарные, сверлильные? Нет! Легкие, средние, тяжелые". Так вот этот язык ассемблера - он строится для процессора с какой архитектурой?

Так трудно набрать -s ? Все, надоел этот маразм. Если хотите что-то спросить, пишите на мыло. Больше на вопросы в темах не отвечаю.

Мне не так уж трудно набрать -s. Мне труднее подобрать способ объяснения человеку, который априори считает себя правым, что выбранные им понятия и термины не относятся к поставленному вопросу. Как насчет ассемблера с load/store подходом? Это тоже ассемблер, но выступающий только как инструмент технической реализации процесса компиляции. А речь идет о разных вычислительных моделях.

А мне вот хамоватый апломб еще не надоел Он меня даже где-то развлекает...

То есть Java-процессор был придуман для того, чтобы все наработки под JVM смогли выполняться аппаратно?

В целом я ничего не могу сказать про соображения авторов Java-процессоров, но когда-то в рамках НИР коллеги показывали презентацию по Jazelle - это аппаратный ускоритель Java для ARM. Сейчас на сайте документация уже где-то в скрытых разделах, но при небольших аппаратных затратах там в демо-ролике получалось, что телефон на обычном ARM показывал 2 чего-то там (fps? или абстрактных баллах?) на довольно навороченной игрушке, а с Jazelle - целых 6. В принципе понятно, что Java хороша своей универсальностью, и при этом какие-то архитектуры выполняют байт-код Java эффективно, а какие-то - не очень. Видимо, должна быть и архитектура, которая будет выполнять такой код максимально эффективно.