Здравствуйте, LaptevVV, Вы писали:

LVV>Оттуда же:
LVV>

LVV>Оригинальные арзитектуры. Лично работал: Днепр, Сетунь, Мир, Русалка, Эльбрус, ПС-2000. Знаю о машинах в остаточных классах. Может что-то ещё было, не вспоминается. Но в начале 90-х Гайдар заявил: "Молодой России электронная промышленность не нужна. Все, что нужно, купим за нефть" И убили.

...
Только в начале 90-х Гайдар мог заявить только "денег нет и взять неоткуда." Вспомните, сколько тогда стоила нефть.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>ЕС-1840 стоила тысячи рублей так что на домашний комп никак не тянула
Были и домашнего применения. Например Ассистент-128, Поиск.

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

Здравствуйте, eskimo82, Вы писали:

E>Много битовых флагов в одном байте или слове разруливаются другими техниками. А персональные команды работы с одиночными битами — это мрачные отголоски CISC подхода, который слава богу, уже помер.

Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
А вообще очень прошу объяснить, почему это вдруг такие команды стали "мрачными отголосками CISC".
Накойхер (tm) требовать переводить в цепочку "загрузить 1 — сдвинуть — выполнить операцию" то, что элементарно выполняется в пределах одной команды чуть более продвинутым железом?
Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?

E>История уже поставила все точки на i.

Я боюсь, что она поставила немного не те точки, чем вы

E>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.

А покажите. Какой-нибудь код общего назначения типа qsort.

Здравствуйте, Michael7, Вы писали:

B>>про "клише" так и не понял, но хочу кинуть пару камней.
B>>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.
M>А в чем тут проявился тормоз в создании ЭВМ или как их называли тогда ЭСМ?
M>Вот сколько не смотрю на историю появления разных там первых МЭСМ и прочих, вижу что МЭСМ начала разрабатываться в 1948-м (!!!) году, не намного-то и позже США и никто разработки такого рода не тормозил ни тогда, ни в 50-х. Как раз в 60-х пошла идея, что нам проще слямзить на Западе, чем своё развивать.

Тормоз был, например, в отсутствии плотного общения с западными коллегами, из-за чего хорошие идеи с трудом пробивались.
Как бы ни был гениален Лебедев, но машина с одним аккумулятором и 15 индексными регистрами это катастрофически перекошенный дизайн. А это ведь великая БЭСМ-6. Код превращался в сплошную загрузку и выгрузку аккумулятора.
Тут приходит S/360 с 16 почти эквивалентными регистрами для всех целей, и сравнение показывает (это был аргумент в дискуссиях за ЕС тех времён), что код на S/360 в ~3 раза короче эквивалента на БЭСМ-6. И это ещё не вспоминая, что последняя была 16-битной в стиле PDP-11 (виртуальная память формата "маленькое окно в большой мир"). Или та же тотальная двоичная иерархия размеров, которая упрощала многие вопросы дизайна чуть более чем полностью.
И это только уровень двоички. А дальше? Тут рассказывали про таблицы перевода, но для них требовались девочки, а не компилятор.

Здравствуйте, eskimo82, Вы писали:

E>>>Z80 — это CPU (в том числе и из спектрума). А вот советский его аналог — микросхема KP580BM80A. И Радио86К, Океан240, и проч. на его основе — где ?
E>>KP580BM80A — это аналог intel 8080.
E>Z80 отличался от 8080 дополнительной (системной) страницей регистров и несколькими дополнительными командами.
E>В целом софт с Z80 нормально работал на KP580BM80A.

Ерунда. Ты наверно запускал на Z80 софт, который был написан для i8080/KP580BM80A, переносил на родную платформу и радовался, что он работает, так?
Система команд у Z80 была кардинально расширена по сравнении с прототипом. И достаточно одной неподдерживаемой команды, чтобы программа не работала. Или ты думаешь, что i8080 просто пропускал незнакомые опкоды, выбирал знакомые и с ними работал как ни в чем не бывало?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>при этом cisc/epic выжили исключительно благодаря грузу совместимости/финансовой мощи ibm&intel. а самостоятельно прлибвшие себе дорогу mips&arm — это только risc. если вспомнить, то alpha и hp pa были закрыты тоже по маркетинговым причинам, обходя на тот момент конкурентов по производительности
Однако в классе серверов до сих пор господствует x86-x64 архитектура. А учитывая любовь к managed коду на серверах, их перевести на другую архитектуру довольно просто. RISC только в мобилах и планшетах сейчас массово юзается. RISC же периодически используют в приставках, но прыгают туда сюда. PS3 на RISC, а PS4 снова x86 совсестима. А приставкам не нужно сохранять совместимость, и тем не менее они периодически выбирают CISC.

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

Здравствуйте, elmal, Вы писали:

E>Кроме программной части, Z80 был попроще в эксплуатации. В частности ему требовалось одно напряжение питания, а не 3, как в intel8080.

Для окончательного уточнения — 3 напряжения требовались только оригинальному 8080. Потом начали выпускать 8080A, который удовлетворялся одним, и 8085, который был развитием, аналогичным Z80, но чуть менее навороченным в расширениях, и который не выдержал конкуренции с Z80 (хотя ещё долго его тянули в интеловском embedded как неплохой SoC).

E> Также число тактов на команду в Z80 и intel8080 разное, z80 работает побыстрее.

Да, его в этом плане хорошо оптимизировали.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>2. у нас одновременно появилось 2 машины с неймановской архитектурой — в москве и киеве, причём независимо разработанных, чуть раньше такая машина появилась в англии, больше нигде в европе их ещё не было. англичане ездили на неймановские ленкции и разрабатывали свою маишу по американсчким ллекалам. я полагаю, что и наши две машины были сделаны по лекциям неймана, благо что они были достаточно массовыми и туда агебты кгб могли проникнуть. иначе тружно объяснить как сразу два коллектива независимо додумались до того чтобы пропустить ошибки, сопутствовавшие разработке ENIAC

Ой, это какие ошибки имеются в виду?

Здравствуйте, eskimo82, Вы писали:

E>Даже книжку откапывать не пришлось, вот сравнительная таблица — система команд одинаковая, но расширеная. Дополнительные команды — это все-то манипуляция с дополнительными регистрами и тесты битов.
Ну и всего-то по-мелочи — добавлены индесные регистры, теневой набор РОН, многие команды расширены доп способами адресации, добавлены короткие относительные переходы, команда цикла DJNZ, команды сравнения с автоинкрементом/декрементом. Чего там, раза в три число команд увеличилось, ерунда

Ну и забыл самую вкуснотищу — блоковые команды LDI/LDIR, LDD/LDDR

Здравствуйте, BulatZiganshin, Вы писали:

BZ>девочки-ассемблеры

и диваны — трансляторы

Здравствуйте, eskimo82, Вы писали:

E>Теневая страница регистров была придумана разработчиками Z80 исключительно для того чтобы не сохранять и стейт регистров при системных вызовах и востанавливать его потом назад. Прикладной програме туда нельзя было, так что это ничего не меняет.

Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры? А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было

E>>Там есть команды относительного перехода относительно текущего счетчика команд. на +-128 байт, сама команда двухбайтовая. В z80 очень активно используется. Если что, в i8080 ничего такого нет, переход там всегда 3 байта занимает (если не считать команду программного прерывания RST), и одной этой новой команды достаточно чтоб ни черта не работало.
E>В i8080 команды перехода — относительные, относительно PC — нынешний короткий джамп на x86 со знаковым 16 битным смещением, это он и есть.
Абсолютные. По твоей же ссылке:

JMP address JP address C3address PC <- address
--- JR index 18index PC <- PC + index

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

Здравствуйте, eskimo82, Вы писали:

E>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.

То-то на ARM'е всякие Thumb'ы прикручивать стали

Здравствуйте, eskimo82, Вы писали:

E>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>1) Z80 и i8080 — это 16 битовые процессоры.
Да шо ви говорите?

2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
Только у RISC всегда команда была одной длины для ускорения обработки, просто некоторые поля могли не использоваться. Плоьность кода была маленькая. Поэтому к нему прикостылили Thumb-режим

Здравствуйте, eskimo82, Вы писали:

E>Да вполне простой RISC укладывается в 1 байт. Но разговор был не том. Если взять один и тот же скомпилированый код, то 32 бит версия для x86 будет _существенно_ длинше чем аналогичная версия для ARM32. Вот и экономия памяти.
Это чушь.
RISC типа быстр и экономичен за счет простоты системы команд — команды совсем примитивные, размер команды строго фиксированный; и поэтому плотность кода существенно ниже, чем у x86.

N> которые противоречат насаждаемым либеральным псевдоисторическим клише в данной области.

Так Гайдар убил в 90е или москали в конце 60х? Видно, что автору хочется пнуть и того и тех, но в итоге получается забавный анекдот, не более.

N> Он потребовал документацию у них. Она пришла. Но по какой-то случайности (Берии уже не было и ответственность практически исчезла) везде не хватало по нескольку страниц, и, самое странное, решающих.

А может и не Гайдар с москалями убили, а эти саботажники?

N>Видимо, Вы смотрели что-то очень древнее, или явно оптимизированное под сокращение размера. Если попросить современный компилятор сгенерировать код с обычными уровнями оптимизации (не какие-нибудь -Os для уменьшения размера), входные точки функций и даже точки начала тела цикла будут выровнены на границу 16 байт. Остаток забивается разными nop'ами. Вот, например, тест xorshift'а, компилятор — clang:
В приведенном Вами коде между командами нет никаких выравниваний.

E>>Да вполне простой RISC укладывается в 1 байт. Но разговор был не том. Если взять один и тот же скомпилированый код, то 32 бит версия для x86 будет _существенно_ длинше чем аналогичная версия для ARM32. Вот и экономия памяти.
M>Это чушь.
M>RISC типа быстр и экономичен за счет простоты системы команд — команды совсем примитивные, размер команды строго фиксированный; и поэтому плотность кода существенно ниже, чем у x86.
Это не чуш. Собери код и сравни — я еще никогда не видел чтобы x86 был бы короче по размеру.

BZ>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
BZ>в risc команды фиксированного размера, включающие код команды, номера гегистров, с котолрыми она работает, режимы адртесации и прочее по мелочи. обычно это 32 бита. есть arm thumb, там размер команды 2/4 байта
для справки.

N>Идея CISC не отвергнута именно потому, что её можно проконвертировать
N>Зато только за счёт конструкции системы команд CISC допускает неограниченное развитие, а RISC — нет. Вон через VEX префикс добавили ещё один аргумент командам. Как ты такое сделаешь на RISC?
Гипотетическое неограниченое развитие системы команд никому не нужно.

N>Вот если они подойдут к порогу остановки — тогда начнётся поиск альтернатив. Собственно, он уже ведётся — каждый следующий техпроцесс сложнее вытягивать. Но покажите мне ARM с аналогом AVX2?
В расширениях ARM есть векторные инструкции и уже довольно давно (еще со времен StrongARMа — это 2003 год примерно).


E>>>И для скорости там выравнивание применяют по границу слова (а для 64 бит и двойного слова кажись), что расточительно черти как. Естественно, что при такой битности сейчас RISC рулит, ибо декодирование команд тривиально.
E>>Код x86 не выравнивается ни по каким границам.
N>См. соседнее сообщение.
См. соседнее сообщение — не выравнивается.

N>Reduced в RISC не потому, что команд мало или они короткие, а потому, что они простые. Никаких сложностей стиля mov ofs(%7), @(%2)+ в PDP-11. Всё исполнение должно уложиться на стандартные 5 тактов (в среднем по архитектурам). При этом ничто не мешает создать 100500 команд под каждый тонкий частный случай.
Как правило, команд мало. Конкретно для ARM — 1 команда (любая) занимает 0.5 такта.

E>>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>>1) Z80 и i8080 — это 16 битовые процессоры.
M>Да шо ви говорите?
См выше. Я там уже все написал.

M>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
M>Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
Опкоды и мелкие данные (до 4 бит).