Эволюция ZX в XXI веке

[Higgins]

Цитата:
Сообщение от Higgins Посмотреть сообщение
1) А кто и как мог бы указывать производителям платформ как эти платформы следует поддерживать инструментарием?
Каким инструментарием? Производителям архитектуры (не платформы!) не надо указывать они делают сами под стандарты ЯВУ и потом появляются записи в ДШ - наше ядро по архитектуре приближено к ЯВУ максимально. Ну кто им это указал как надо приблизить? Как считаете? Или вы хотите сказать что они сами всю жизнь ЯВУ разрабатывали и теперь по своим же рекомендациям делают? Но некоторые вообще не имеют собственных компиляторов ЯВУ. Кстати их очень много. Но это не мешает им писать "архитектура наиболее приближена к ЯВУ".

Инструментарий -- значит средства разработки.

О производителях архитектур и "приближенности к ЯВУ в ДШ".

1) Я сходу не могу назвать ни одного производителя программируемых аппаратных архитектур, который не был бы представлен в рабочих группах ISO. Поэтому в некоторой степени эти производители влияют на то, что говорят стандарты. И не только стандарты на сами языки, но и множество других нормативов, имеющих отношение к делу.

2) Фразы рекламного толка в ДШ совершенно не обязательно отражают что-то объективно существующее. Особенно в таком туманном деле, как удобство для компиляции с Си и Си++ (если правильно понял, какие фразы вы имеете в виду).

3) Практика в вопросе об удобстве компиляции (либо любой автоматической генерации кода) состоит в том, что сами принципы, позволяющие генерировать эффективный код с Си и Си++ -- они сложились еще во времена K&R, то есть давно известны и с тех пор практически не изменились. Вообще, в этой части комитеты ориентируются на отражение в стандартах существующей практики, нежели на навязывание своей точки зрения на то, как это должно быть.

Я подчеркиваю: все эти бесчисленные изменения в стандартах практически целиком относятся к фронтам компиляторов. Это редкий случай, когда изменение стандарта затрагивает генерацию кода. И приживаются такие вещи очень долго.

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

5) Не понятно, какое все это имеет отношение к правильности разделения требований к инструментария на те, которые определяют язык и те, которые действуют в рамках платформы. Слова об изворачивающемся производителе компилятора тоже не понятны. Да, изворачиваются. И не только, чтобы угодить упомянутым тут бумагам и соглашениям. Требований очень много. Это часть работы таких производителей, и они об этом знают. ;-)

Сколько производителей архитектур (не платформ!) делающих компиляторы сами Вы можете назвать? Сколько лицензируют у других?

Крупные производители (Intel, ARM, TI) лицензируют плюсовые фронты (EDG, Metrowerks) и пишут кодогенерацию сами. Производители средней руки (Microchip) заказывают разработку и затем покупают разработчика (Hi-Tech). (Это не мешает крупным производителям (ARM) покупать независимых разработчиков (Keil).) Мелкие производители аутсорсят.

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

Я бы не стал вообще упоминать Страуструпа. Поскольку Си++ в той части, которая имеет отношение к теме ссылается на Си, а на развитие Си Страуструп имеет, мягко говоря, небольшое влияние.

Ах вот как значит формирует все таки? То есть моим же салом по моим же мурсалам? Оно знаете конечно не как либо что, и что либо как...

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

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

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

Дословно я сказал следующее:

Именно. Но производительность, с оговорками про сброс конвейера, все-таки увеличим (фазы инструкций исполняются параллельно).

Конвейеризация означает параллельное исполнение стадий инструкций в конвейере. Да, это стадии разных инструкций, но исполняются они параллельно.

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

Не примите за наезд, но это настолько общеизвестно и очевидно, что объяснять я это здесь не буду. Отложим это туда, где уже лежат разговоры о том, что процессорного ядра не может быть рядом с ПЛИС и о том, что размер корпуса -- это характеристика платформы. ;-)

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

Перестанут. На неконвейеризированном ядре исполнение инструкций не делится на части так, как это происходит на конвейере.