yacc: Все сообщения за 6 Января 2024 года

zaitcev> И это я ещё на твоей стороне. ЕС однозначно был прогресс а ув. Татарин заблуждается. Но твои аргументы нужно подтянуть. Оставь байтовые операции и душу С.А.Лебедева в покое.
Я Татарину предлагаю выбрать любую другую нашу ЭВМ.
Но он зациклился на БЭСМ-6.

Ну не подходит БЭСМ-6 для универсальной.

•  инфо
•  инструменты
• Ответить на сообщение

zaitcev> Новосибирцы в своё время портировали Unix на БЭСМ-6
не слышал никогда о таком порте

На СМ-1420 сам с Демосом работал.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Татарин> Ну, я про то и говорю, что ЯВУ взяли бы на себя такие операции и научились бы приводить индекс суб-словного операнда к адресу слова и индексу в слове.
Но они это делать НЕ СТАЛИ.

Татарин> Я почему и упрекаю тебя в бессмысленном актуализме: ты принимаешь далёкие следствия принятых решений (например, конкретный синтаксис ЯВУ) за некое препятствие или фактор при принятия решения. Это бессмысленно целиком и полностью.
Я наглядно показываю что БЭСМ-6 на бизнес-задачах тормозила.
Ты упираешься в то что "могли бы".

Татарин> Нет смысла спрашивать, как реализовать код на Паскале, если в той реальности адаптированный Паскаль (или, скорее, Алгол) был бы совсем иным.
Но НЕ СТАЛ.
Это можно наглядно посмотреть на эволюции реализации компилятора Паскаля для CDC 6000, ссылку на который я привел.
Как была простая реализация строкообработки с костылем типа alfa, так она и осталась.

Татарин> Собссно, нет ничего сложного в синтаксисе типа
Татарин> alfa* str = "1234567890";
Еще раз - это нет ничего сложного для олимпиадников.
Средний программист даже не будет париться - сделает через char.
Потому что средний программист подготовлен тем же техникумом/ПТУ в те времена - это для работы над задачами народохозяйственного значения - т.е. планово-экономических.
Средний программист возьмет книжку типа Семашко Г.Л., Салтыков А.И. 'Программирования на языке Паскаль' - Москва: Наука, 1988

И далее возьмет строкообработку за пример "Программа изменения длины строк текста (пример использования записей с вариантами)"

А там простой array[1..NMAX] of char
C последующими тормозами при выполнении на аккумуляторной архитектуре БЭСМ-6, что я наглядно показал.
Причем в книге есть упоминание типов alfa - прямо в оглавлении книги.
Но никто этого программиста не учил оптимизации на уровне прикладной программы с учетом архитектуры машины и особенности системы команд, потому что техникум/ПТУ.


Татарин> ЯВУ - это одновременно и следствие из существующего железа, и изолирующий интерфейс между ним и программистом. Был бы актуален alfa - был бы и полный набор для работы с ним.
Паскаль содержит все необходимое для реализации работы с ним.
Но далее этот тип, как появилась адресация байтами, попросту убрали, за ненужностью.
Сам Вирт и убрал.

Татарин> Как бы это сказалось на скорости обработки тогдашних задач? Да примерно никак.
Строкообработка не была типовой задачей для БЭСМ-6 или CDC 6000. Поэтому никто и не парился с оптимизацией.

Татарин> Фишка быстродействия БЭСМ-6 была в том, что сейчас было бы принято называть кешем
Да, там был кэш, на 8 значений адресов. Т.е. если адрес МОЗУ помечен как находящийся в кэше, то обновляться значение будет в кэше, а обновится в самом МОЗУ на момент выкидывания адреса из кэша.
НО! Как я уже сказал, сам работа с PACKED написана на самом Паскале, а не на ассемблере - и там тоже дофига переменных в реализации функции. Т.е. простая пробежка по переменным - это с учетом задания параметров цикла и других переменных, а в моем простом примере их было 3, плюс реализация самого PACKED - привет работа с ОЗУ. Т.е. тормоза на ровном месте, там, где на архитектуре с регистрами - типа PDP или 360 - можно было бы использовать сами регистры, гораздо более скоростные.

Татарин> Сразу скажу, что я не сторонник именно такого решения: явно именованные регистры имеют большие выгоды, как минимум в плотности кода (сколько бит адресуют обычно РОН? а сколько память?)
Вот народ посмотрел и оценил что программы на 360 по использованию ОЗУ меньше чем у БЭСМ-6.

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

Татарин> Именно по части прямой совместимости снизу вверх тут, например, сплошные выгоды: ты можешь наращивать регистровый файл без изменения системы команд. Просто у тебя на новом процессоре СТАРЫЕ программы без всякой переделки начинают работать быстрее.
Эволюция архитектуры пошла в сторону эльбруса, а не в сторону оптимизации БЭСМ-6 для бизнес-задач, типа увеличения кэша.
Это мы сейчас достоверно знаем.

•  21
•  инфо
•  инструменты
• Ответить на сообщение

yacc>> Но ты их не показываешь, а уперся в БЭСМ-6. Причем даже не посмотрел что там все вокруг аккумулятора и ОЗУ крутится.
Татарин> БЭСМ - это реально чисто "аккумуляторная" архитектура без явно выделенного файла РОН.
Именно.
И без адресации байтов.

Татарин> Но у этого технического решения есть не только существенные недостатки, но и существенные преимущества, возможности альтернативного развития, чего ты реально не видишь
У меня есть послезнания в виде как реализации Паскаля на такой архитектуре, так и развития ЭВМ в целом по архитектурам.
Добавить регистры и команды работы с ними было проще чем уперто сохранять аккумуляторную архитектуру.
Причем на слабых и простых PDP это давало существенные плюсы. Плюс сами PDP были гораздо дешевле.

Татарин> Потому что если просто смотреть на всю эту бодягу с нашим послезнанием, то... что есть архитектура и система команд? Это не более, чем контракт между софтом и железом.
Я не философ в отличии от тебя.
Для меня это использование железа максимально производительным способом.
Для счетных задач аккумуляторная архитектура с кэшем - годится, но при высоких скоростях машины. Или когда надо просто подкрутить ранее созданную и отлаженную подобную же архитектуру но без кэша.
А для убитого железа регистры - гораздо более удачное решение, чтобы выжать скорость.
Без всяких кэшей.

Татарин> Была ли система команд и архитектура ИБМ/360 чуть лучше БЭСМ, была ли она чуть более приспособлена для выполнения более общих задач? Да. Но ЭТО НЕ ИМЕЕТ НИКАКОГО ЗНАЧЕНИЯ.
Татарин> Вообще никакого.
Именно что имеет.
Причем существенное.
Архитектура 360 расчитана на средних программистов. Там все просто и наглядно - есть регистры.
А вот считать частоту использования кэша и оптимизация под то, чтобы реализация минимум лезла бы в МОЗУ - это для гиков/олимпиадников.
Собственно БЭСМ или CDC и поставлялась туда, где были сильные программисты, а не средним.

Татарин> Что-то БЭСМ могла делать только более сложным образом, что-то более простым (и ты вот это не видишь на универсальных задачах совсем, а это есть, и ещё как), но это неважно. Важно то, что здесь-и-сейчас она могла предоставить более широкий функционал и быстрое развитие, чем клоны ИБМ/360.
Еще раз - гики/олимпиадники.
А для бизнес-задач нужна периферия. Это Ива правильно сказал. Но ты это не понимаешь.


Татарин> Это чем-то похоже на гонку Ф1, в которой гонщики несутся по треку, выигрывают доли секунды на виражах, заезжают на пит-стопы по необходимости, где за секунды только меняют колёса и заливают самое необходимое, чтобы рвануть дальше... И вот тут на пит-стоп заскакивает советский болид
Гонка в бизнес-задачах - это гонка задач с широким использованием периферии.
А не оптимизации аккумуляторных процессоров.
И да - американский болид-противник для ИМиВТ - это был CDC. Который тоже плевал на бизнес-сферу.
А потом и Cray-1 с распараллеливанием.

yacc>> Ну не прижились нигде машины с адресацией длинных слов!
Татарин> По историческим причинам. Которые для нас совершенно неважны.
По объективным причинам.
Потому что широкому классу пользователей это НЕ НУЖНО и ОЧЕНЬ СЛОЖНО.
Вон тебе ПЗ просто и понятно говорит: "я не хочу напрягать мозги всякими альфами, я хочу чтобы было по простому, потому что это сокращает время написания моей прикладной программы и просто и понятно для всех с точки зрения логики. Лезть в высокие математики я не хочу и не собираюсь"
Нет никаких "заговоров" масонов, ЦРУ, СлаваКПСС и подобного, как ты это хочешь представить, что аккумуляторные архитектуры массово не выжили.

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

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Татарин> А это неважно потому, что никто не говорит о там, чтобы заставить лично Лебедева все гаки крутить. Он мог спокойно себе заниматься высокопроизводительными машинами...
Татарин> Собссно, мы же говорим о стандарте?
Примечательно что сам Лебедев был за стандарт 360, только от ICL.
Но исключая суперкомпьютеры типа БЭСМ-6.

Татарин> Вот были коллективы, которые раскручивали по винтикам ИБМ/360, а потом лепили 100%-совместимые машины в том числе так, как сами себе это представляли. А могли бы лепить БЭСМ-совместимые.
А ты эти коллективы спросил ? Их мнение ?
Эти коллективы имели свои линейки машин - типа Минска или Раздана - и имели собственное мнение какой должна быть машина.
Причем коллектив Минска был наиболее компетентным в СССР по части планово-экономических машин - от производства до сопровождения, т.е. реально знал потребности тех самых средних программистов и плановиков, ибо сопровождал эти машины на такого рода задачах.
В плане планово-экономических машин коллектив Минска был наиболее компетентным в СССР и гораздо более компетентным чем ИМиВТ с Лебедевым вместе.

И что этот коллектив сказал когда ему предложили выбор между реализацией младшей 360 от ICL с готовой проектной документацией, а не напряжению своих сих на реализацию ЕС 1020 ( а она не была копией 1 в 1 ) ?
Он сказал что ему это неинтересно!

Наглядно с совещания:

Крутовских. Все разработчики, кроме Рамеева, не хотят переориентироваться на фирму ICL. P-50 будет готова в 1971 г.

 

С чего ты взял что Минск добровольно и с радостью бы согласился модифицировать БЭСМ-6 по которой была полная документация ? ( да, это существенная экономия времени как бы )

И да - ты не ответил на это EC ЭВМ и ДВК. Решение о клонировании IBM и PDP - причины и последствия [yacc#03.01.24 15:50]

•  инфо
•  инструменты
• Ответить на сообщение

Татарин> Во-первых, "бизнес-задачи" и "обработка строк" - ну очень разные вещи.
Обработка строк - одна из самых нужных в бизнес-задачах.
Про decimal я даже еще не начинал - его тоже не было в БЭСМ-6

Татарин> Во-вторых, в СССР на ближайшие лет 10, до конца 80-х, основными задачами будут расчётные, как мы знаем из нашей реальности: как научно-технические, так и бухгалтерия, где до "бизнеса" - пропасть.
Бухгалтерия - это значимая часть бизнес задач.
В малых фирмах - так точно.

Татарин> А количественно 8 слов + аккумулятор - это сильно больше, чем, например, в х86, где всего 4 РОН вместе с аккумулятором, плюс 2 индексных - SI, DI (меньше, чем у БЭСМ).
А ничего что х86 еще и байтовую адресацию имеет ?
Сдвиг указателя на третий символ - там вообще одной командой. Без танцев с бубнами.

Татарин> И, конечно, хватило бы и БЭСМ.
Т.е. ты усердно за то чтобы все танцевали с бубнами ?

Татарин> Тебе придётся всё же чуть напрячься, выдумывая какой-то особый алгоритм, где 8 регистров не хватило бы для нормальной работы
Нет у тебя фиксированных 8 регистров.
Просто нет!
Еще раз - нет!
На х86 или 360 ты написал чтобы что-то было в регистре - и 100% это там будет.
А вот в кэше да при реализации оператора ЯВУ ( который сам написан алгоритмом на ЯВУ ) - это сугубо вероятностное событие.
Причем наиболее вероятно что там его и не будет, если выпускник ПТУ написал прикладную программу.

Татарин> Тем более, что мы знаем и общую производительность ЕС и БЭСМ на реальных задачах (и компиляторах тоже) и в синтетике, БЭСМ - серьёзно выигрывает.
А ничего что ветстоун как и гибсон - это научно-технические задачи ?

Татарин> И твой аргумент в том, что на строковых задачах БЭСМ будет выигрывать не так сильно или даже проигрывать? И?
И то, что Минск ничем не хуже БЭСМ-6 для них

По ГОРАЗДО БОЛЕЕ ДЕШЕВОЙ ЦЕНЕ.
Так понятно ?

Татарин> У него в БЭСМ просто не будет char. Только и всего.
У него в БЭСМ есть char.
Это доказано практикой компилятора Паскаль на реальных БЭСМ-6.
Это достоверно известно.
Так что мимо.

Татарин> Ты вообще понимаешь, что ставишь у себя в голове на одну полку во многом произвольное решение какого-то американского разработчика не самого популярного языка и судьбу компутерной отрасли СССР?
См. выше про Минск.

yacc>> Строкообработка не была типовой задачей для БЭСМ-6 или CDC 6000. Поэтому никто и не парился с оптимизацией.
Татарин> Ну вот в альтернативной реальности, где стандартом стала бы БЭСМ, строковая обработка стала бы со временем одной из типовых задач и потребовала бы поддержки как аппаратуры, так и в ЯВУ (и получила бы их). Это можно было бы сделать добрым десятком способов, это никак не мешало советсткой отрасли все эти 10 лет жить, развиваться, генерировать и воплощать новые идеи, разработывать железо и софт.
Еще раз читать про Минск.

•  20
•  инфо
•  инструменты
• Ответить на сообщение

yacc>> У меня есть послезнания в виде как реализации Паскаля на такой архитектуре, так и развития ЭВМ в целом по архитектурам.
Татарин> Ты вот это вот всё говоришь искренне, так что я даже не знаю, как тут аргументировать даже.
Это достоверный факт.
А не альтернативная реальность, которую ты тут пытаешься создать.

Татарин> Ну абсурдно же. Аккумуляторная архитертура именно что ПРОЩЕ. Бери - да используй всю память как хочешь. И да, в абсолютном большинстве случаев 8 псевдо-РОН более чем достаточно.
Простота она поначалу, когда на транзисторах. Для первых эвм.
Потому что регистр - это дорого.
Потом эта простота уже чревата низкой скоростью.
И поэтому и в МиниЭВМ и в процессорах всегда были регистры.
Никто даже и не подумал использовать аккумуляторную архитектуру в микропроцессорах.
Как ты это объяснишь ?

yacc>> Еще раз - гики/олимпиадники.
Татарин> "Метод дятла"(тм)
Если ты не имеешь опыта в реальных проектах прикладных приложений с текучкой - то это не мои проблемы.

Татарин> Как это отменяет наличие на БЭСМ тех же компиляторов?
Ты сознательно тупишь?
Код компилятора 70-х годов я тебе наглядно дал.
Еще раз - 70-х.

Татарин>Или, допустим, ЮНИКСа, как тут приводят пример?
Единичный пример ?
Единичный пример это расчет на ПМК пи с точностью до дофига знаков.
Так, задача ради задачи - взять да раскинуть остальные знаки после запятой по 14 регистрам.


Татарин> И с "гиковостью" - такая же чушь.
Это факт.

Татарин> На ЯВУ разницы не было бы никакой, а программирование в машкодах под CISC-машину типа ИБМ/360 в любом случае очень нудное занятие
Разница в реализации и выполнения в машкодах для БЭСМ-6 и CISC - значительно отличается.
Для CISC как проще сделать так и быстрее будет работать учитывая байтовую адресацию

Татарин> Очевидно же, что расширение/достройка БЭСМ для работы со строками более чем посильная задача
А что, Минск ускорить непосильная ?

•  инфо
•  инструменты
• Ответить на сообщение

yacc>> А ты думаешь такого не было у капиталистов ?
Татарин> Ну вот там, где было, там и старались ставить CDC. Да-да, вот прям так и было.
CDC ставили только там, где были задачи научно-технического характера.

yacc>> Или может на условный завод им Комсомола ( а в реальности выпускающий танки ) приходили посчитать все кто захочет в данном городе ? Ну например ЦСУ или Сберкасса ?
Татарин> Поначалу - приходили
Нет.
Не было никакого микса ведомств кроме самых первых ЭВМ еще на лампах.
Вообще не было.
Подумай почему.

Татарин> Я знаю, что в центрах общего пользования в собственности государства стояли как раз CDC.
В научных центрах.

И да, я так и не услышал вменяемого и обоснованного объяснения наличия массовых младших моделей как 360 так и наших Минсков кроме всяких там "заговоров". При том, что как бы стоимость одной операции у них была ниже.

•  инфо
•  инструменты
• Ответить на сообщение