Процессор - интерпретатор С

[Ism]

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

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

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

Написанное лишь смутная догадка. Как и то , что это реализуемо только при жесткой стандартизации и вынесении в отдельный сороцессор.
Правда есть видеокарты с OpenCL и CUDA , но это очень неоптимальные устройства несмотря на их высокую производительность

[liaonau]

Чрезвычайно маловероятно, что, скажем, в Intel никто об этом не задумывался. Возможно что стоимость такого процессора будет выше суммарной стоимости процессоров выдающих такую же производительность?
Когда-то SUN разрабатывали аппаратную JVM. Не взлетело.

[DaemonTux]

Вопрос что курил афтар?

Учите матчасть.

С одной стороны:
В любом проце есть декодер который преобразует машинный код (читай ASM) в во внутренний код проца ( обычно там risc подобные команды для задействования определенных блоков ЦП)
Грубо говоря благодаря внутреннему декодеру получаются такие фичи как выполнение несколько инструкций за такт, несколько потоков на ядро, etc.

С другой мы имеем что многие популярные и часто используемые функции требующие много машинного времени сильно оптимизируются.
А именно переписываются на asm. Мало того что их переписываю на asm для arm, x86, power, sparc, mips, etc. Ну и зачастую в пределах одной архитектуры есть разные реализации под возможности конкретной линейки процов. Например для x86 могут быть функции на системе команд i486, sse, avx. И уже конкретная версия выбирается либо при компиляции библиотеке либо в момент исполнения.

[Ism]

В любом проце есть декодер который преобразует машинный код (читай ASM) в во внутренний код проца ( обычно там risc подобные команды для задействования определенных блоков ЦП)

Гениально С++ -> ASM -> RISC
Когда мне может нужно только 2+2 сложить.

Вопрос что курил афтар?

Учите матчасть.

Именно поэтому я и завел эту тему, чтоб прояснить данный вопрос

[Ism]

С другой мы имеем что многие популярные и часто используемые функции требующие много машинного времени сильно оптимизируются.
А именно переписываются на asm. Мало того что их переписываю на asm для arm, x86, power, sparc, mips, etc. Ну и зачастую в пределах одной архитектуры есть разные реализации под возможности конкретной линейки процов. Например для x86 могут быть функции на системе команд i486, sse, avx. И уже конкретная версия выбирается либо при компиляции библиотеке либо в момент исполнения.

То есть по сути применяются многоуровневые костыли рассчитанные изначально на некачественный ASM код. Получается оптимизатор сам решает что и как выполнять вместо меня.
Но если я сам хочу точно указать, что и как хочу выполнить. Если я знаю точно , что хочу получить на выходе ? Почему я не могу действовать в обход оптимизатора ?
Да, это чревато , что я повешу намертво проц вклинившись в поток команд. Но тогда можно вынести все в сопроцессор который только принимает данные и возвращает результат

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

[SinClaus]

Гуглим про системы Burroughs или, по русски, Эльбрус (Эль-берроуз).

[DaemonTux]

Но если я сам хочу точно указать, что и как хочу выполнить. Если я знаю точно , что хочу получить на выходе ? Почему я не могу действовать в обход оптимизатора ?

Указывайте кто вам мешает? для этого есть куча методов. Переписывания критических участков на асм. Просадки в производительности обычно появляются из за неправильного предсказания ветвления. Из за чего нужно подгружать порцию данных из RAM так как их в кеше нет, а это очень дорогая операция процессор пропускает кучу тактов. Есле жи вы знаете что конкретное в ветвление будет с вероятностями 99/1 % вы можете сообщить об этом компилятору.

Так что плодить нужно не новые апаратные блоки на каждый чих. А устранять бутылочное горлышко CPU <-> RAM

[DaemonTux]

И вообще прочитайте Что должен знать програмист о памяти.

[rm_]

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

Всё это называется CISC, и в описываемом вами экстремальном варианте уже пробовалось,
см. например
https://en.wikipedia.org/wiki/Intel_iAPX_432
https://en.wikipedia.org/wiki/I960.

The iAPX 432 was "designed to be programmed entirely in high-level languages",[3] with Ada being primary. Direct hardware support for various data structures was intended to allow modern operating systems for the 432 to be implemented using far less program code than for ordinary processors; combined with direct support for object-oriented programming and garbage collection

Не взлетело.

[deadhead]

Почему я не могу действовать в обход оптимизатора ?

ассемблерные вставки не оптимизируются

Гениально С++ -> ASM -> RISC

именно для того что бы код был портируем на *другие* платформы (кстати в случае x86 С++ -> ASM -> CISC -> RISC)

P.S.

но это очень неоптимальные устройства несмотря на их высокую производительность

как бы этим все и сказано... ну еще разве что ценовой фактор стоит учитывать ;)

[Ism]

но это очень неоптимальные устройства несмотря на их высокую производительность

как бы этим все и сказано... ну еще разве что ценовой фактор стоит учитывать

Но если все разделить и оптимизировать, то будет гораздо эффективней. Почему оптимизированный под графику чип должен заниматься распределенными вычислениями ?

[xorader]

Более того, я где то читал, что уже есть процессоры со встроенной java-машиной. Это к примеру...

[drBatty]

Как известно все языки программирования формируют машинный код , который потом выполняется прцессором.
Но следствие этого очень неоптимальная работа машинных команд. Часто чтоб выполнить простую операцию типа вычисления sin() или поиска подстроки в строке пишется очень громоздкая с точки зрения машинного кода программа.

кто вам такое сказал? sin уже есть в FPU, а поиск тоже есть с i8086. Что ещё вы хотите воткнуть в процессор?

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

так оно и есть IRL. Вы придумали велосипед. Парадоксально - но вы придумали велосипед сидя на велосипеде ☺

[Bizdelnick]

так оно и есть IRL

Уже давно не совсем так. Нет там никаких особо навороченных железячных схем, они оказались неэффективными и теперь просто эмулируются.

я где то читал, что уже есть процессоры со встроенной java-машиной

Аналогично, байт-код сначала преобразуется в нативные инструкции дополнительной прослойкой, а потом выполняется.

[deadhead]

Но если все разделить и оптимизировать, то будет гораздо эффективней. Почему оптимизированный под графику чип должен заниматься распределенными вычислениями ?

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

[karpen]

Есть аппаратная реализация шифрования AES в процессорах от Intel. Чем это не сложнее 2+2? И сколько нужно хранить данных в процессоре (допустим 8-ми битном) когда нужно оперировать числами 16 бит? Уже привыкли к 64 битам и поэтому не учитываете особенности архитектуры того или иного процессора (были и 128 битные процессоры - не знаю, может регистры аккумулятора или шины адреса) и фортран, оберон машины были.

[drBatty]

Уже давно не совсем так. Нет там никаких особо навороченных железячных схем, они оказались неэффективными и теперь просто эмулируются.

понятно что не совсем так просто, как я расписал (а ТС придумал). Делать свой блок на каждую команду ессно расточительство, проще сделать несколько блоков, и на лету собирать из них конвейеры(тоже упрощённо, но ближе).

Уже привыкли к 64 битам и поэтому не учитываете особенности архитектуры того или иного процессора (были и 128 битные процессоры - не знаю,

SSE2 128и битная. Уже есть.

[VAA]

«МИР» — серийная ЭВМ для инженерных расчётов, создана в 1965 году Институтом кибернетики Академии наук УССР, под руководством академика В. М. Глушкова. Одна из первых в мире персональных ЭВМ. Выпускалась серийно и предназначалась для использования в учебных заведениях, инженерных бюро, научных организациях. Имела ряд уникальных особенностей, таких как аппаратно реализованный машинный язык, близкий по возможностям к языкам программирования высокого уровня, развитое математическое обеспечение.

Язык - АЛГОЛоподобный, т.е. вполне себе высокого уровня. Даже очень высокого, с учетом аппаратных возможностей. Скромное "близкий по возможностям к языкам программирования высокого уровня" - только потому, что не был стандартизован в таком качестве.

Оперативная память: 4096 12-разрядных слов (время выборки — не более 2,5 мкс, физический носитель — ферритовые сердечники)
Внешняя память: 8-дорожечная перфолента. Устройство ввода FS-1501 (до 1500 символов/сек.), устройство вывода ПЛ-80 (до 80 символов в секунду).
Быстродействие: 200—300 оп/сек для операций над 5-разрядными числами

Входной язык машины — АЛМИР-65.

Скромное "близкий по возможностям к языкам программирования высокого уровня" - только потому, что не был стандартизован в таком качестве. А так - не хуже ALGOL-60. Ввспомните - серийное производство с 1965 года! До ALGOL-68 дело еще не дошло. А что касается Си:

Си (англ. C) — стандартизированный процедурный язык программирования, разработанный в начале 1970-х годов

Если говорить только о реализации самого языка C, без библиотек - он даже проще АЛМИР-65. А библиотеки - это только объем ПЗУ.

В качестве входного языка в машине МИР-2 использовался специальный язык высокого уровня АНАЛИТИК, который развивал концепции встроенного языка программирования МИР-1 и дополнительно позволял непосредственно формулировать задания с аналитическими преобразованиями формул, позволял получать аналитические выражения для производных и интегралов.

http://ru.wikipedia.org/wiki/%D0%9C%D0%98%D0%A0

Так что учите историю, она ходит по спирали и новые идеи - забытые старые.

[Ali1]

Семейство процессоров КРОНОС разработано в Вычислительном центре СО АН СССР в рамках проекта МАРС (Модульные Асинхронные Развиваемые Системы).

Цель разработки - создание универсального процессора с аппаратной поддержкой языков высокого уровня для конструирования ЭВМ открытой архитектуры: от встроенных микро-ЭВМ и однопроцессорных рабочих станций до многопроцессорных ЭВМ класса супер-мини. Здесь дается обзор архитектуры процессоров и операционной системы для них.

КРОНОС - общее название семейства 32-разрядных процессоров, предназначенных для создания микро- и мини-ЭВМ.

Архитектура процессоров КРОНОС ориентирована на поддержку языков программирования высокого уровня (Си, Модула-2, Паскаль, Оккам и т.п.), что позволяет реализовать новейшие концепции в области использования ЭВМ.

http://kronos.ru/literature/processors

Про АДА-процессор iAPX 432 уже говорили.
LISP-машины.

[SinClaus]

С кронусятами я был знаком, во многом эль-барроузная архтектура, "обратная польская запись" и сплошь стековые операции. Ассемблера как такового не было, сразу писали компиляторы с Фортрана, если не ошибаюсь, или Модулы. И параллельно - вроде ещё Аду прикручивали, там народу было довольно много.

[Ali1]

SinClaus
Модулы.
И "юникс" на модуле сделали https://code.google.com/p/kronos/


ЗЫ
Прообраз:
A Brief History of Modula and Lilith
N. Wirth

Lilith -- http://www.cfbsoftware.com/modula2/Lilith.pdf

[SinClaus]

Ну, когда мы к ним ходили в гости, типа чаю попить, при визитах в Н-ский Академгородок из Томского, у них там крутилась Кронос-ОС, насчёт портирования стандартного Юникса мы за чаем только беседовали.

[MrClon]

Но если я сам хочу точно указать, что и как хочу выполнить. Если я знаю точно , что хочу получить на выходе ? Почему я не могу действовать в обход оптимизатора ?

Например потому-что процессор лучше тебя знает как он устроен, как можно оптимизировать выполнение и так далее. Если минимизировать число посредников то полуим либо камень который нельзя изменить не сломав совместимость (а значит камень который будет обсолютно ненужен через пару лет, ибо устареет), либо 100500 разных стандартов которые придётся поддерживать.
Определись чего-ты хочешь: впиливания в процессор (ну или отдельный сопроцессор, хотя такой вариант едва-ли взлетит коммерчески) аппаратных реализаций популярных задач, или максимально прямого доступа к процу? Эти задачи, в некотром роде, противоположны:
На сколько я знаю в современных процах (во всяком случае x86 совместимых) «высокоуровневые» комманды (всякие там SSE и прочее) не реализуются аппаратно (как это предполагает архитектура CISC), собственно аппаратно реализуются только максимально примитивные логические оппирации (архитектура RISC), CISC комманды транслируются в RISC самим процом.
Так-же есть чисто RISC архитектуры. В любом случае аппаратная (в смысле совсем аппаратная) реализация сложной логики это определённо не тренд, где-то с середины девяностых наверное.

[Ism]

Но если я сам хочу точно указать, что и как хочу выполнить. Если я знаю точно , что хочу получить на выходе ? Почему я не могу действовать в обход оптимизатора ?

Например потому-что процессор лучше тебя знает как он устроен, как можно оптимизировать выполнение и так далее. Если минимизировать число посредников то полуим либо камень который нельзя изменить не сломав совместимость (а значит камень который будет обсолютно ненужен через пару лет, ибо устареет), либо 100500 разных стандартов которые придётся поддерживать.
Определись чего-ты хочешь: впиливания в процессор (ну или отдельный сопроцессор, хотя такой вариант едва-ли взлетит коммерчески) аппаратных реализаций популярных задач, или максимально прямого доступа к процу? Эти задачи, в некотром роде, противоположны:
На сколько я знаю в современных процах (во всяком случае x86 совместимых) «высокоуровневые» комманды (всякие там SSE и прочее) не реализуются аппаратно (как это предполагает архитектура CISC), собственно аппаратно реализуются только максимально примитивные логические оппирации (архитектура RISC), CISC комманды транслируются в RISC самим процом.
Так-же есть чисто RISC архитектуры. В любом случае аппаратная (в смысле совсем аппаратная) реализация сложной логики это определённо не тренд, где-то с середины девяностых наверное.

Хотелось бы уточнить, смысл не совсем том, чтоб засунуть высокоуровневые функции в железо. А в том, чтоб разделить управляющий поток команд и вычислительный, то есть процессор не должен быть комбайном и например заниматься шифрованием или подобными вещами. От процессора требуется получить данные и отправить куда надо на обработку, а обработкой должна заниматься другая железяка. Предположим это чтото типа CUDA которая заточена именно на ускорение вычислений. А эту железяку можно будет перепрощивать, чтоб функционал был на уровне. Этакий железософт
В общем написал смутно, но гдето так.

[MrClon]

Что-то вроде того что используется в современной мобильной технике например для работы с видео? Вынос востребованных и вычислительно сложных задач в отдельный аппаратный модуль?

[Ism]

Что-то вроде того что используется в современной мобильной технике например для работы с видео? Вынос востребованных и вычислительно сложных задач в отдельный аппаратный модуль?

Чтото типа этого, но более гибкое и не зависящее от платформы.

[Vexhin]

не зависящее от платформы.

А как железо может быть независящим от платформы? Вы этот сопроцессор физически не воткнёте в материнскую плату, которая его не поддерживает.

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