OSDev

Вот вы зациклились, умным должен быть и компилятор и процессор. Подправить компилятор под новый процессор не велика проблема. В современных компиляторах оптимизация инструкций не зашита в коде компилятора, а описывается декларативно в текстовых скриптах.
PS. По-русски хинт - подсказка (такое слово употребляется в различной документации от MS).

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

Хотя если речь идёт о том, что "а надо ли париться ?", тогда да - пусть будет монополия и не будет прогресса, ведь нам плевать.

Давайте немного конкретики, каких данных вам не хватает. Я лично не вижу проблемы. Через MSR читается море информации о микроархитектуре процессора и кэша. Пусть там что-то и упустили из виду, но мне кажется доступно 99% данных, значимых для оптимизации.
Между тем я с вами согласен, что процессор не может оптимизировать алгоритмы программы, каким бы большим он не был. Процессор может быть умным только для себя (в части пакетного выполнения команд, и в части уменьшения собственных накладных расходов), но не для программы. Функциональных процессоров, выходящих за рамки элементарных арифметических операций, ещё не существует.

Шутки ради
mov -> =
mul -> *
div -> /
jz... -> if(...)
jmp -> goto
call -> function()

С помощью команды rdtsc можно примерно оценить длительность инструкции. Впрочем это не имеет ни какого смысла, т.к. команды с неопределённым количеством тактов не являются спариваемыми, они выполняются монопольно.
Какими внутренностями вы хотите управлять?

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

Здесь необходимо выполнить две загрузки из памяти или кэша или регистров (для x и y) - как я могу понять, где конкретно находятся x и y ? Как я могу сказать системе заранее закэшировать эти переменные (за 200 тактов до реального вычитания/умножения) и не трогать это место в кэше ? Как я могу понять, за сколько же на самом деле тактов я должен подсуетиться и прочитать переменные в кэш ? И это только вопросы по операции загрузки двух переменных.

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

Далее идёт сохранение данных. Нас интересуют две новых переменных - a и b. Если из дальнейшего текста программы я знаю, что a понадобится через 100 тактов, а b понадобится через 100 000 тактов - как я могу наиболее рационально разместить эти переменные в кэшах нужных уровней ?

И при всём при этом как я могу учесть наличие других задач, которые в виде обработчиков прерываний или в виде параллельных потоков потрут все мои кэши и похерят все мои ожидания ? То есть я хотел бы иметь возможность добавить в планировщик задач информацию о гарантированном хранении данных в течении заданного периода в заданном кэше - как я могу это сделать ?

Надеюсь возражения вроде:более не должны так легко озвучиваться

Шутки ради - а как будет выглядеть название function() ?

Я считаю, что эти проблемы надуманы. Я полагаю, что в суперскалярных в процессорах используется упреждающее чтение в кэш, и это решает проблемы загрузки данных к нужному времени, точно в нужный момент.
Насчёт автоматического распараллеливания, за это вроде отвечают технологии типа OpenMP, которые уже внедрены в стандарты всех компиляторов. В случае выполнения всего двух вычислений, то компилятор эффективно использует спаривание инструкций в одном ядре, без использования многоядерной параллельности.
Если вам очень интересна тема оптимизации до самых тонкостей, то вам наверно будут интересны статьи небезызвестного Агнера Фога
http://www.agner.org/optimize/
Я давно ещё читал несколько старых статей первых выпусков, пока они ещё были в пределах понимания для рядового программиста. Из них я понял основные моменты и направление мысли, всё остальное - для специалистов, конкретно занимающихся изготовлением компиляторов, не стоит забивать голову.

Можно сказать, что так же. Ассемблерный оператор proc имеет синтаксис сходный с Си - имеет параметры, локальный стек и локальные переменные на нём. По крайней мере так было в Borland Turbo Assembler с синтаксисом Ideal.

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

За распараллеливание отвечает только компилятор, а всяческие красивые названия технологий - это всего лишь чья-то реклама и продвижение собственных продуктов (Permanent members are vendors who have a long-term interest in creating products for OpenMP).

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

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

Так, к слову.
Если компилировать код на Си без использования оптимизации вообще, то декомпиляция будет относительно вменяемой назад в Си.
Если бы было возможно включить хорошую оптимизацию при транслировании кода на Java в байт-код, то восстановить это было бы не сильно проще, чем Си из ассемблера. Только разница в том, что ни один JAVA-компилятор (до байт-кода) не производит никакой толковой оптимизации (а многие компиляторы - никакой вообще). В первую очередь поэтому JAVA неплохо декомпилируется. Никаких специфических конструкций, помогающих в декомпиляции, в байткоде попросту нет. Самая обычная стековая машина, да еще и туповатая. Все условия и циклы, как и в обычном ассемблере, превращаются в связки goto с проверкой (только вместо проверки флага можно сразу проверить результат вычитания). Имена полей-методов - не аргумент в пользу декомпиляции, т.к. это не логика кода, это просто, так сказать, обязательная дебаг-информация (которая, к слову, может быть изменена в бессвязный бред с сохранением работоспособности программы).
В то же время я видел java-программы, которые сдекомпилировать было сложнее, чем многие сишные. Но их мало, т.к. никто не заморачивается с этим - зачем дважды оптимизировать (сначала байт-код, а потом еще и после компиляции в ассемблер). Не говоря о том, что даже для обычной скомпилированной без оптимизации жабы декомпиляторы иногда выдают в корне неверный (логически) код.