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

[AlexeyAS]

1) А кто и как мог бы указывать производителям платформ как эти платформы следует поддерживать инструментарием?

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

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

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

3) ANSI уже давно никак не трактует Страуструпа. Во-первых, потому, что стандартизация ведется в рамках международной рабочей группы ISO, представленной членами рабочих групп национальных комитетов по стандартизации. Во-вторых, современный Си++ уже насколько далек от страуструповского ARM, что трактовать там уже нечего. В-третьих, сам Страуструп с первых дней стандартизации и по сей день участвует в работе группы, поэтому любые трактовки излишни.

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

4) Стандарты на Си и Си++ пользуются абстрактными машинами, а не виртуальными машинами.

Нет ну а это то зачем????? Я нигде не говорил про виртуальные машины, кроме как в первых постах этого форума где речь шла о JVM.

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

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

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

Ах вот как значит формирует все таки? То есть моим же салом по моим же мурсалам? Оно знаете конечно не как либо что, и что либо как...
Вообще зря мы схлестнулись здесь, может лучше в приват? И отфтопить не будем?

---------- Post added at 00:44 ---------- Previous post was at 00:40 ----------

1) Прочитал несколько раз, так и не понял, о какой ошибке речь. То, что вы написали не противоречит тому, что конвейер означает параллельное исполнение стадий разных инструкций.

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

2) На нековейеризированном ядре исполнение инструкций не делится на стадии. ;-)

Это к чему?

Запустите эти стадии с частотой F на конвеерезированном устройстве и на не конвеерезированном - они буду выполнены за одно и тоже время

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