Инструментарий -- значит средства разработки.Сообщение от AlexeyAS
О производителях архитектур и "приближенности к ЯВУ в ДШ".
1) Я сходу не могу назвать ни одного производителя программируемых аппаратных архитектур, который не был бы представлен в рабочих группах ISO. Поэтому в некоторой степени эти производители влияют на то, что говорят стандарты. И не только стандарты на сами языки, но и множество других нормативов, имеющих отношение к делу.
2) Фразы рекламного толка в ДШ совершенно не обязательно отражают что-то объективно существующее. Особенно в таком туманном деле, как удобство для компиляции с Си и Си++ (если правильно понял, какие фразы вы имеете в виду).
3) Практика в вопросе об удобстве компиляции (либо любой автоматической генерации кода) состоит в том, что сами принципы, позволяющие генерировать эффективный код с Си и Си++ -- они сложились еще во времена K&R, то есть давно известны и с тех пор практически не изменились. Вообще, в этой части комитеты ориентируются на отражение в стандартах существующей практики, нежели на навязывание своей точки зрения на то, как это должно быть.
Я подчеркиваю: все эти бесчисленные изменения в стандартах практически целиком относятся к фронтам компиляторов. Это редкий случай, когда изменение стандарта затрагивает генерацию кода. И приживаются такие вещи очень долго.
4) Сегодня трудно себе представить, что производитель, продвигающий не то, что целую архитектуру, а просто конкретное ядро, не предоставлял бы в месте с ним инструментальный набор, как минимум включающий компилятор с Си. Конечно, он может не заниматься разработкой такого пакета самостоятельно, привлекая для этого третьи стороны.
5) Не понятно, какое все это имеет отношение к правильности разделения требований к инструментария на те, которые определяют язык и те, которые действуют в рамках платформы. Слова об изворачивающемся производителе компилятора тоже не понятны. Да, изворачиваются. И не только, чтобы угодить упомянутым тут бумагам и соглашениям. Требований очень много. Это часть работы таких производителей, и они об этом знают. ;-)
Крупные производители (Intel, ARM, TI) лицензируют плюсовые фронты (EDG, Metrowerks) и пишут кодогенерацию сами. Производители средней руки (Microchip) заказывают разработку и затем покупают разработчика (Hi-Tech). (Это не мешает крупным производителям (ARM) покупать независимых разработчиков (Keil).) Мелкие производители аутсорсят.
Я бы не стал вообще упоминать Страуструпа. Поскольку Си++ в той части, которая имеет отношение к теме ссылается на Си, а на развитие Си Страуструп имеет, мягко говоря, небольшое влияние.
Да, формирует. Да, можно сказать, что для абстрактной машины. Но это, мягко говоря, с натяжкой, потому что к тому для конкретного компилятора промежуточное представление обычно генерируется не в терминах абстрактной машины входного языка, а (во многом) в терминах круга тех целевых платформ, которые поддерживает фронт. Что касается промежуточного кода, которое вы упомянули, то так принято называть гораздо более низкоуровневое представление, как правило с большим количеством завязок на целевую платформу.
В любом случае абстрактная машина -- это просто способ описания, которым пользуются стандарты на языки. Компилятор может пользоваться ею, а может и не пользоваться, до тех пор пока соблюдены требования.
Дословно я сказал следующее:
Да, на той же частоте с конвейером с оговорками про сброк конвейера будем иметь производительность выше.
Не примите за наезд, но это настолько общеизвестно и очевидно, что объяснять я это здесь не буду. Отложим это туда, где уже лежат разговоры о том, что процессорного ядра не может быть рядом с ПЛИС и о том, что размер корпуса -- это характеристика платформы. ;-)
Перестанут. На неконвейеризированном ядре исполнение инструкций не делится на части так, как это происходит на конвейере.
Ответить с цитированием
