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

N>>>Одно отсутствие целочисленной арифметики чего стоит
ЕМ>>А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?

N>Оно мешало тем, что толщина кода на всё, что не было непосредственно вычислениями с плавающей точкой, на ней становилось дороже в несколько раз.

Какая еще "толщина кода"? За счет чего "дороже в несколько раз"? Можете объяснить подробнее? Только имейте в виду, что Вы про эту систему команд лишь где-то отрывочно читали, а я непосредственно в ней программировал несколько лет.

N>А так как даже просто подсчитать индексы в матрице это целочисленные вычисления, то подобная диверсия била по всему.

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

N>В IBM это поняли давно и сделали хотя бы систему команд универсальной с возможностью адаптации под конкретный стиль

Я знал немало людей, одновременно работавших на уровне системы команд как с IBM/ЕС, так и с БЭСМ-6. Ни разу не слышал сколько-нибудь систематических жалоб на любую из них. Обе были достаточно комфортны в постоянной работе, и лишь при первом знакомстве каждая казалась неудобной. А Вы где черпаете сведения?

ЕМ>>Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?).

N>Если "локальность" это "у нас машина для численных расчётов, а всё остальное пофиг", то да, в курсе. Если что-то другое — уточните, какую именно из 100501 локальностей вы тут имеете в виду.

Я имею в виду принцип локальности, он один, и работает везде, в том числе и в численных расчетах. Про остальные 100500 я не в курсе, Вас не затруднит бегло перечислить хотя бы десяток?

N>Ну а "большинство" задач в которых нельзя считать что-то размером больше чем 100x100 без жутких извратов...

Да Вы, похоже, толком и не представляете, как это работает. Вам вообще приходилось делать на ассемблере/автокоде не короткие вставки для ЯВУ, а достаточно сложные законченные программы?

N>В сегментной организации можно хотя бы без регулярного напряга ОС обратиться к другому сегменту, просто загрузил номер и пошёл. А тут что — просить ОС каждый раз хлопать страницами?

Какая разница, кого просить — процессор или ОС? В 286 переключение сегментов тоже занимало далеко не один такт. Переключение страниц через ОС, конечно, работало медленнее, но и там, и там грамотное программирование заключалось в том, чтобы не делать этого без нужды.

N>>>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.

N>как раз описывают не связанное с библиотеками — а именно код типа "перемножить матрицу на вектор".

Можно примеров, где это прям "в несколько раз"?

N>Единственность аккумулятора — вообще самая первая глупость дизайна, которая приводит к тому, что операции загрузить в аккумулятор и выгрузить из него занимают больше всего остального.

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

N>в линии PDP (не обязательно PDP-11!) есть куда более интересные примеры. И даже CDC1604 (и похожие), с которой любят сравнивать БЭСМ-6...

Да почти в любой системе команд есть "интересные примеры". Но среди серийных машин нет примеров явно, бесспорно неправильных и неудобных систем команд. Если машина пошла в серию — значит, она была признана пригодной для большинства применений, на которые была ориентирована.

N>>>Ностальгировать по этому смысла просто ноль целых фиг десятых.

ЕМ>>Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".

N>cейчас под те же 8051 продолжают писать реальные шедевры. Или есть конкурсы по минимизации объёма, доходящие до "Pacman в 90 байт".

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

N>>>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.
ЕМ>>А термин "безнадежен" — конкретизируемый?

EM>> Алгол-68 "круче" C++ прежде всего в плане сложности

N>потому он и почти забыт — что его сложность была неоправданной.

Это отдельный вопрос. Вы скажите, каким образом эту сложность сумели реализовать (и не раз) те "древние люди", что работали с "ужасами дизайна", не используя ни ООП, и ФП, ни прочих страшных слов?