-
![[image]](https://www.balancer.ru/cache/sites/it/re/redd/i/128x128-crop/aoun1wrmj8z71.png)
EC ЭВМ и ДВК. Решение о клонировании IBM и PDP - причины и последствия
необходимость или причина развала СССР?Теги:
yacc
Татарин> Вопрос знакомый. Самое в нём полезное, что для того, чтобы его задать, совершенно не нужно думать, что и доказано СлавойКПСС. 
Самое главное у тебя - это вовремя вставить СлаваКПСС чтобы любую свою чушь типа счета для бухгалтерии на РЕФАЛе у нас или на западе на ЛИСПе, которая отсутствовала в реальности, оправдать.
Типа "художника может каждый обидеть. Мы на Рефале зарплаты считать будем, так вижу!"
Самое главное у тебя - это вовремя вставить СлаваКПСС чтобы любую свою чушь типа счета для бухгалтерии на РЕФАЛе у нас или на западе на ЛИСПе, которая отсутствовала в реальности, оправдать.
Типа "художника может каждый обидеть. Мы на Рефале зарплаты считать будем, так вижу!"
инфо
инструменты
Татарин
yacc> Типа "художника может каждый обидеть. Мы на Рефале зарплаты считать будем, так вижу!"
Предыдущий комментарий подходит и как ответ на это.
Тут тот самый случай, когда аргументация высокого уровня примитивизируется и теряет смысл, соотвественно, более тупой становится более правым как бы автоматически.
...
Нет, на самом деле была масса способов приладить работу с текстами к БЭСМ-6. Многие из них давали лучшие результаты, чем у ИБМ, и даже отсутствие специальной работы с символами вообще дало бы по итогам лучшие результаты, чем введение ЕС (просто из-за отсутствия задержек и зависимостей из нашей реальности).
Но показать существующую альтернативную реальность, ессно, невозможно.
Собссно, поэтому остаётся простой технический аргумент: тыкать коммуняк в кучку г**на наделанную СлавойКПСС в нашей реальности. Тыкать до тех пор, пока способность утверждать, что это всё шоколад, а ссаньё - это роса от бога, не исчерпается.
Долго, да. Опять же, на твоём примере, не факт, что даже это сколь-нить работает. Всё равно ж роса, правда? А ЕС - ммм, шоколад сплошной.
Предыдущий комментарий подходит и как ответ на это.
Тут тот самый случай, когда аргументация высокого уровня примитивизируется и теряет смысл, соотвественно, более тупой становится более правым как бы автоматически.
...
Нет, на самом деле была масса способов приладить работу с текстами к БЭСМ-6. Многие из них давали лучшие результаты, чем у ИБМ, и даже отсутствие специальной работы с символами вообще дало бы по итогам лучшие результаты, чем введение ЕС (просто из-за отсутствия задержек и зависимостей из нашей реальности).
Но показать существующую альтернативную реальность, ессно, невозможно.
Собссно, поэтому остаётся простой технический аргумент: тыкать коммуняк в кучку г**на наделанную СлавойКПСС в нашей реальности. Тыкать до тех пор, пока способность утверждать, что это всё шоколад, а ссаньё - это роса от бога, не исчерпается.
Долго, да. Опять же, на твоём примере, не факт, что даже это сколь-нить работает. Всё равно ж роса, правда?
А ЕС - ммм, шоколад сплошной.
Татарин> На новых процессорах Интел уже думала отказаться от всего до-64 битного.
Да оно и так уже не ехало. Практически.
Так что тут "озвучивают де-факто". ИМХО.
Татарин> Нет, главное тут - само устройство выборки, которое генерирует два запроса на шину.
А можно уложиться в один цикл. Плохо ли?
Татарин> Считанное, ессно, идёт (вот сейчас идёт) в защёлку,
В защелку "подлиннее" - из нее можно быстро выбрать нужный (до "байта") кусок данных. Привычной разрядности.
Да оно и так уже не ехало. Практически.
Так что тут "озвучивают де-факто". ИМХО.
Татарин> Нет, главное тут - само устройство выборки, которое генерирует два запроса на шину.
А можно уложиться в один цикл. Плохо ли?
Татарин> Считанное, ессно, идёт (вот сейчас идёт) в защёлку,
В защелку "подлиннее" - из нее можно быстро выбрать нужный (до "байта") кусок данных. Привычной разрядности.
Татарин> Тут тот самый случай, когда аргументация высокого уровня примитивизируется и теряет смысл
Не я постоянно СлаваКПСС пихаю везде.
Татарин> Нет, на самом деле была масса способов приладить работу с текстами к БЭСМ-6.
Никому это было нафиг не нужно.
Бухгалтерам нужен по факту Эксель.
РПГ, который начал свою жизнь еще на 1401 и потом в 360 - вот что им надо.
А не высокие материи.
Татарин>Многие из них давали лучшие результаты, чем у ИБМ, и даже отсутствие специальной работы с символами вообще дало бы по итогам лучшие результаты
Факт в том, что БЭСМ - Счетная машина - на это и была заточена.
Татарин> Но показать существующую альтернативную реальность, ессно, невозможно.
А ее и не было бы с БЭСМ.
Только тебе она в голову приходит.
Никому больше ни тут, ни у отцов-основателей, в голову не приходило делать из БЭСМ-6 универсальную ЭВМ.
А ... ну да - СлаваКПСС же виноват!
Не я постоянно СлаваКПСС пихаю везде.
Татарин> Нет, на самом деле была масса способов приладить работу с текстами к БЭСМ-6.
Никому это было нафиг не нужно.
Бухгалтерам нужен по факту Эксель.
РПГ, который начал свою жизнь еще на 1401 и потом в 360 - вот что им надо.
А не высокие материи.
Татарин>Многие из них давали лучшие результаты, чем у ИБМ, и даже отсутствие специальной работы с символами вообще дало бы по итогам лучшие результаты
Факт в том, что БЭСМ - Счетная машина - на это и была заточена.
Татарин> Но показать существующую альтернативную реальность, ессно, невозможно.
А ее и не было бы с БЭСМ.
Только тебе она в голову приходит.
Никому больше ни тут, ни у отцов-основателей, в голову не приходило делать из БЭСМ-6 универсальную ЭВМ.
А ... ну да - СлаваКПСС же виноват!
Татарин> На новых процессорах Интел уже думала отказаться от всего до-64 битного. Все инструкции, которые тянутся с 8080 (типа коррекции BCD) могут быть отброшены, консультации по этому вопросу идут.
То есть, в русле дискуссии, кому надо совместимость-эмулируейте оболочкой, правильно я понимаю?
То есть, в русле дискуссии, кому надо совместимость-эмулируейте оболочкой, правильно я понимаю?
Татарин>> Нет, на самом деле была масса способов приладить работу с текстами к БЭСМ-6.
yacc> Никому это было нафиг не нужно.
Если бы ты знал немного больше об истории техники в СССР или процессорных архитектурах, я мог бы спросить "почему?". Но в данном случае, как мы оба знаем, ты говоришь это просто "патамучто", смысла спрашивать нет.
Пример с Альфами я приводил (а это были очень успешные машины даже в х86 мире, погибшие только вместе с DEC и убитые уже Compaq). Но вот возьмём другую не-х86 архитектуру наших дней, компутеры "Эппл", которые долгое время жили на архитектуре PowerPC Это настолько уж общеупотребимо-попсово-универсальная система, что ставить под сомнение бухгалтерию на Эпплах можно уже только в крайней стадии идиотизма или с терминальным СлаваКПСС. И вот смотри: там тоже 64-битные регистры общего назначения, а из "байтовых" операций - загрузка/сохранение байта и вектора.
И всё это прекрасно же бежало. Почему не могло бежать на БЭСМ?
yacc> Бухгалтерам нужен по факту Эксель.
Сомнительное утверждение, но...
В 60-х? ТОЧНО нет. И ещё очень долго нет.
yacc> Факт в том, что БЭСМ - Счетная машина - на это и была заточена.
Ты повторяешь это бессмысленное утверждение, по факту не имея за ним совершенно ничего.
Но даже если принять его за истину (ну, допустим, я обдолбаюсь до того уровня, когда голова работает как у коммуниста), то никаких проблем к минимальной доработке этой машины не было.
Не было нужды всё уничтожать и делать так, чтобы СССР НАВСЕГДА отстал от Штатов, принципиально исключая всякую возможность догнать (какое там уж про "перегнать"). Догнать копируя - невозможно.
yacc> Никому больше ни тут, ни у отцов-основателей, в голову не приходило делать из БЭСМ-6 универсальную ЭВМ.
Ну, это ты так думаешь. По факту же - СВС, ну и как дальний потомок - "Эльбрус". Которые, как финал этой истории, и остались единственной архитектурой универсальных процессоров, унаследованных в какой-то степени от СССР.
И единственной архитектурой СССР как-то пережившей его распад.
И да, конечно, в том, что всё остальное сдохло из-за полной нежизнеспособности - СлаваКПСС. И то, что "Эльбрус" не развивался - СлаваКПСС. И сам факт того, что ты думаешь, что "никто не думал сделать из БЭСМ универсальную машину", то, что ты плюёшь на советских разработчиков, на их труд и реальную историю - тоже чистый, дистиллированный СлаваКПСС и далёкий итог программы ЕС.
Собссно, сам факт того, что коммунисты в этом топике сторонники вечной убогости и отсталости СССР - это чистый СлаваКПСС.
yacc> Никому это было нафиг не нужно.
Если бы ты знал немного больше об истории техники в СССР или процессорных архитектурах, я мог бы спросить "почему?". Но в данном случае, как мы оба знаем, ты говоришь это просто "патамучто", смысла спрашивать нет.
Пример с Альфами я приводил (а это были очень успешные машины даже в х86 мире, погибшие только вместе с DEC и убитые уже Compaq). Но вот возьмём другую не-х86 архитектуру наших дней, компутеры "Эппл", которые долгое время жили на архитектуре PowerPC Это настолько уж общеупотребимо-попсово-универсальная система, что ставить под сомнение бухгалтерию на Эпплах можно уже только в крайней стадии идиотизма или с терминальным СлаваКПСС. И вот смотри: там тоже 64-битные регистры общего назначения, а из "байтовых" операций - загрузка/сохранение байта и вектора.
И всё это прекрасно же бежало. Почему не могло бежать на БЭСМ?
yacc> Бухгалтерам нужен по факту Эксель.
Сомнительное утверждение, но...
В 60-х?
ТОЧНО нет. И ещё очень долго нет. yacc> Факт в том, что БЭСМ - Счетная машина - на это и была заточена.
Ты повторяешь это бессмысленное утверждение, по факту не имея за ним совершенно ничего.
Но даже если принять его за истину (ну, допустим, я обдолбаюсь до того уровня, когда голова работает как у коммуниста), то никаких проблем к минимальной доработке этой машины не было.
Не было нужды всё уничтожать и делать так, чтобы СССР НАВСЕГДА отстал от Штатов, принципиально исключая всякую возможность догнать (какое там уж про "перегнать"). Догнать копируя - невозможно.
yacc> Никому больше ни тут, ни у отцов-основателей, в голову не приходило делать из БЭСМ-6 универсальную ЭВМ.
Ну, это ты так думаешь.
По факту же - СВС, ну и как дальний потомок - "Эльбрус". Которые, как финал этой истории, и остались единственной архитектурой универсальных процессоров, унаследованных в какой-то степени от СССР.И единственной архитектурой СССР как-то пережившей его распад.
И да, конечно, в том, что всё остальное сдохло из-за полной нежизнеспособности - СлаваКПСС. И то, что "Эльбрус" не развивался - СлаваКПСС. И сам факт того, что ты думаешь, что "никто не думал сделать из БЭСМ универсальную машину", то, что ты плюёшь на советских разработчиков, на их труд и реальную историю - тоже чистый, дистиллированный СлаваКПСС и далёкий итог программы ЕС.
Собссно, сам факт того, что коммунисты в этом топике сторонники вечной убогости и отсталости СССР - это чистый СлаваКПСС.
Татарин>> На новых процессорах Интел уже думала отказаться от всего до-64 битного. Все инструкции, которые тянутся с 8080 (типа коррекции BCD) могут быть отброшены, консультации по этому вопросу идут.
iodaruk> То есть, в русле дискуссии, кому надо совместимость-эмулируейте оболочкой, правильно я понимаю?
Типа того.
Вам это не нужно©.
На самом деле, на серверах это давно уже так. Там вполне определённый набор софта и места неоптимизированному закрытому легаси коду без возможности перекомпиляции просто нет.
iodaruk> То есть, в русле дискуссии, кому надо совместимость-эмулируейте оболочкой, правильно я понимаю?
Типа того.
Вам это не нужно©.
На самом деле, на серверах это давно уже так. Там вполне определённый набор софта и места неоптимизированному закрытому легаси коду без возможности перекомпиляции просто нет.
Татарин> Если бы ты знал немного больше об истории техники в СССР или процессорных архитектурах, я мог бы спросить "почему?".
Это как раз тот, кто со старыми архитектурами не знаком, пихает их рандомно куда не попадя.
БЭСМ и CDC - в бухгалтерию.
Ты чего куришь?
А все потому что MIPSы глаза затмевают...
Татарин> Пример с Альфами я приводил (а это были очень успешные машины даже в х86 мире, погибшие только вместе с DEC и убитые уже Compaq).
Не надо приводить в пример то, что ты сам не щупал.
Не было там никаких суперспособностей.
Татарин> Но вот возьмём другую не-х86 архитектуру наших дней, компутеры "Эппл", которые долгое время жили на архитектуре PowerPC
... и внезапно там увидим байты... ага с системы 360, а не 48-битные слова как БЭСМ или 60 битные как у CDC.
Внезапно и там байты! А не 6 символов по 7 бит в 48 битном слове с пустыми местами.
И да - аж инструкции по работе с байтами!
Но СССР с БЭСМ и 48 битным словом мог всех порвать! Только СлаваКПСС помешала
Татарин> И всё это прекрасно же бежало. Почему не могло бежать на БЭСМ?
См. выше
И читай эскизный проект БЭСМ-10 - нет там никаких байтов и байтовой адресации.
Зато черным по белому написана цель достижения максимальных скоростей в научно-технических задачах.
yacc>> Бухгалтерам нужен по факту Эксель.
Татарин> Сомнительное утверждение, но...
Татарин> В 60-х? ТОЧНО нет. И ещё очень долго нет.
И в 60!
Тупая задача массового счета по вводным данным и простым формулам.
Часть задач вообще табуляторы тогда делали.
yacc>> Факт в том, что БЭСМ - Счетная машина - на это и была заточена.
Татарин> Ты повторяешь это бессмысленное утверждение, по факту не имея за ним совершенно ничего.
Это следует из ее использования и эскизного проекта БЭСМ-10 где черным по белому указано назначение.
Татарин> Но даже если принять его за истину (ну, допустим, я обдолбаюсь до того уровня, когда голова работает как у коммуниста), то никаких проблем к минимальной доработке этой машины не было.
Это у ТЕБЯ их нет - ты же это реализовывать не собираешься.
А вот скажем у Урала реализацию всего-навсего символьной ( а-ля байтовой ) адресации ОЗУ отложили чтобы вписаться в план сдачи ЭВМ. Потому что это схемы. Как МОЗУ так и процессора.
Попробовать, протестировать так и так, подумать поправить и опять попробовать. Пока не найдено работающее решение.
Это тебе, зумеру - тяп-ляп и готово! А в реале КБ занимается кроме проектирования новых машин еще и поддержкой старых и фиксами, контактирует с заводами-изготовителями, делает заказные решения для военных. И людей перманентно нехватает.
Ну приведут тебе молодых специалистов ( "джунов" ) так их год только в курс дела вводить надо.
И это, казалось бы, простая задача - всего лишь адресация.
Про перефигачивание конвейера БЭСМ-6 я молчу.
Очевидно что Лебедев и Бурцев, в отличии от тебя, были реалистами. И даже не стали париться с байтами, если понятно было что рано или поздно на горизонте появится Крей-1 и задаст новые стандарты производительности. И Сеймуру Крею тоже было пофиг на байтовую адресацию и работу со строками.
yacc>> Никому больше ни тут, ни у отцов-основателей, в голову не приходило делать из БЭСМ-6 универсальную ЭВМ.
Татарин> Ну, это ты так думаешь. По факту же - СВС, ну и как дальний потомок - "Эльбрус". Которые, как финал этой истории, и остались единственной архитектурой универсальных процессоров, унаследованных в какой-то степени от СССР.
Эльбрус выжил благодаря Бабаяну.
И да - даже сейчас для бухгалтеров он избыточен.
И да - это не совсем универсальная архитектура - просто другой не осталось.
Татарин> Собссно, сам факт того, что коммунисты в этом топике сторонники вечной убогости
У тебя даже не научная фантастика, когда ты предлагаешь альтернативный вариант, а натуральная фентези в стиле поттерианы
Еще раз - выбирай другую ЭВМ СССР для базовой.
Это как раз тот, кто со старыми архитектурами не знаком, пихает их рандомно куда не попадя.
БЭСМ и CDC - в бухгалтерию.
Ты чего куришь?
А все потому что MIPSы глаза затмевают...
Татарин> Пример с Альфами я приводил (а это были очень успешные машины даже в х86 мире, погибшие только вместе с DEC и убитые уже Compaq).
Не надо приводить в пример то, что ты сам не щупал.
Не было там никаких суперспособностей.
Татарин> Но вот возьмём другую не-х86 архитектуру наших дней, компутеры "Эппл", которые долгое время жили на архитектуре PowerPC
... и внезапно там увидим байты... ага с системы 360, а не 48-битные слова как БЭСМ или 60 битные как у CDC.
Внезапно и там байты! А не 6 символов по 7 бит в 48 битном слове с пустыми местами.
И да - аж инструкции по работе с байтами!
Но СССР с БЭСМ и 48 битным словом мог всех порвать! Только СлаваКПСС помешала
Татарин> И всё это прекрасно же бежало. Почему не могло бежать на БЭСМ?
См. выше
И читай эскизный проект БЭСМ-10 - нет там никаких байтов и байтовой адресации.
Зато черным по белому написана цель достижения максимальных скоростей в научно-технических задачах.
yacc>> Бухгалтерам нужен по факту Эксель.
Татарин> Сомнительное утверждение, но...
Татарин> В 60-х?
ТОЧНО нет. И ещё очень долго нет. И в 60!
Тупая задача массового счета по вводным данным и простым формулам.
Часть задач вообще табуляторы тогда делали.
yacc>> Факт в том, что БЭСМ - Счетная машина - на это и была заточена.
Татарин> Ты повторяешь это бессмысленное утверждение, по факту не имея за ним совершенно ничего.
Это следует из ее использования и эскизного проекта БЭСМ-10 где черным по белому указано назначение.
Татарин> Но даже если принять его за истину (ну, допустим, я обдолбаюсь до того уровня, когда голова работает как у коммуниста), то никаких проблем к минимальной доработке этой машины не было.
Это у ТЕБЯ их нет - ты же это реализовывать не собираешься.
А вот скажем у Урала реализацию всего-навсего символьной ( а-ля байтовой ) адресации ОЗУ отложили чтобы вписаться в план сдачи ЭВМ. Потому что это схемы. Как МОЗУ так и процессора.
Попробовать, протестировать так и так, подумать поправить и опять попробовать. Пока не найдено работающее решение.
Это тебе, зумеру - тяп-ляп и готово! А в реале КБ занимается кроме проектирования новых машин еще и поддержкой старых и фиксами, контактирует с заводами-изготовителями, делает заказные решения для военных. И людей перманентно нехватает.
Ну приведут тебе молодых специалистов ( "джунов" ) так их год только в курс дела вводить надо.
И это, казалось бы, простая задача - всего лишь адресация.
Про перефигачивание конвейера БЭСМ-6 я молчу.
Очевидно что Лебедев и Бурцев, в отличии от тебя, были реалистами. И даже не стали париться с байтами, если понятно было что рано или поздно на горизонте появится Крей-1 и задаст новые стандарты производительности. И Сеймуру Крею тоже было пофиг на байтовую адресацию и работу со строками.
yacc>> Никому больше ни тут, ни у отцов-основателей, в голову не приходило делать из БЭСМ-6 универсальную ЭВМ.
Татарин> Ну, это ты так думаешь.
По факту же - СВС, ну и как дальний потомок - "Эльбрус". Которые, как финал этой истории, и остались единственной архитектурой универсальных процессоров, унаследованных в какой-то степени от СССР.Эльбрус выжил благодаря Бабаяну.
И да - даже сейчас для бухгалтеров он избыточен.
И да - это не совсем универсальная архитектура - просто другой не осталось.
Татарин> Собссно, сам факт того, что коммунисты в этом топике сторонники вечной убогости
У тебя даже не научная фантастика, когда ты предлагаешь альтернативный вариант, а натуральная фентези в стиле поттерианы
Еще раз - выбирай другую ЭВМ СССР для базовой.
Это сообщение редактировалось 04.01.2024 в 20:44
Татарин> Грубо говоря, для программиста невелика разница при обработке строк указать вместо [адрес_байта] нечто типа [адрес_слова], [номер_байта_в_слове]. Одна-две "лишние" операции: поделить на число байт в слове и результат деления - поместить адрес, а остаток - в номер байта.
Велика.
Вот пусть эти "одну-две лишние операции" процессор и делает.
И мне пофик как.
Ровно тоже можно сказать и про арифметику.
Что достаточно булевой логики, а остальное - это пара-тройка, ну или десяток другой лишних операций.
Ведь правда?
У меня в "системе команд" должны быть инструкции с байтовой адресацией.
Остальное не мое дело.
"Тчк"
Велика.
Вот пусть эти "одну-две лишние операции" процессор и делает.
И мне пофик как.
Ровно тоже можно сказать и про арифметику.
Что достаточно булевой логики, а остальное - это пара-тройка, ну или десяток другой лишних операций.
Ведь правда?
У меня в "системе команд" должны быть инструкции с байтовой адресацией.
Остальное не мое дело.
"Тчк"
Ещё раз про лубоФФ:
В 1966 г. в СКБ завода закончилось создание ЭВМ «Минск-23», предназначенной для обработки данных при решении планово-экономических задач, задач статистики, управления производством, информационного поиска. Главным конструктором был В. В. Пржиялковский, заместителем главного конструктора — Г. Д. Смирнов.
Быстродействие «Минск-23» Рис. 5
составляло около 7 тыс. операций в секунду. Емкость оперативной памяти — 40 тыс. восьмибитных символов (байтов). Цикл работы ОЗУ и машины — 13 мкс. Емкость адресного ЗУ, предназначенного для хранения адресов команд и операндов, программных и информационных базисов, а также текущих адресов обмена с устройствами ввода-вывода — 127 ячеек по девятнадцать бит каждая. Система счисления — десятичная (десятично-двоичная), запятая фиксирована после младшего разряда, форма представления чисел и команд — символьная последовательность переменной длины. Адресность команд — переменная. Адреса команды базируются и индексируются. Имеются команды, представляющие собой целые процедуры обработки данных. [4]
«Минск-23» имела структуру и систему команд, полностью отличающуюся от существовавших до этого ЭВМ. Эта первая отечественная машина с символьной логикой и переменной длиной слова и команды. Машина имела развитую систему прерывания и приостановок, универсальную связь с внешними устройствами (фактически — байт-мультиплексный канал), защищенную область памяти с обслуживающими программами, возможность использования большого количества индексных полей для каждого программного массива, специальные команды редактирования и обработки полей переменной длины, состоящих из алфавитно-цифровых символов. [5]
В ЭВМ «Минск-23» реализован мультипрограммный режим работы. Она обеспечивает выполнение трех рабочих и пяти служебных программ одновременно. При этом она могла взаимодействовать по восьми направлениям с 64 внешними устройствами одновременно.
В комплект поставки входили устройство ввода с перфокарт (600 карт/с), устройство ввода с перфоленты (1000 строк/с), алфавитно-цифровое печатающее устройство (400 строк/мин), перфоратор карт (100 карт/мин), ленточный перфоратор (80 символов/с).
Впервые в отечественной вычислительной технике с «Минск-23» началась поставка накопителя на магнитной ленте НМЛ-67 — накопителя рулонного типа с плотностью записи 32 имп./мм, совместимого с западными накопителями. Накопитель был разработан в КБПА (Конструкторское бюро промышленной автоматики) бригадой во главе с В. Г. Макурочкиным и доведен до промышленных норм в СКБ завода им. Г. К. Орджоникидзе (с 1966 г. — Минское проектное бюро завода им. Г. К. Орджоникидзе). Для специализированных систем, использующих ЭВМ «Минск-23», в МПБ завода им. Г. К. Орджоникидзе были разработаны устройство "Бланк", считывающее 150 формализованных бланков с карандашными отметками (гл. конструктор — Надененко В. К.), и аппаратура передачи данных по телефонным каналам "Минск-1500" (В. Е. Клочков и Е. И. Мухин).
Для машины «Минск-23» был предложен язык символьного кодирования ССК, на котором составлялось все системное программное обеспечение. Библиотека системных стандартных программ помимо модулей, предназначенных для вычисления элементарных функций, содержала программы, осуществляющие обращение к устройствам ввода-вывода с перекодировкой и редактированием, программу сортировки, обслуживания накопителя на магнитной ленте, служебные программы.
В комплект поставки входил также транслятор с Автокода, машинно-ориентированного языка с большим количеством макросов, обслуживающих ввод-вывод и библиотеку стандартных программ. В состав транслятора был включен также загрузчик, готовивший модули загрузки.
Впервые в состав программного обеспечения отечественных ЭВМ в СПО «Минск-23» вошла операционная система (монитор пакетной обработки, сборщик-загрузчик, связь оператора с машиной, система определения сбоев, координатор мультипрограммной обработки). Возглавлял разработку программного обеспечения машины Марголин М. С.
На базе ЭВМ «Минск-23» были созданы автоматизированные системы управления Новочеркасского электровозостроительного завода, Московского объединения «Мосмолоко» , система продажи и резервирования авиабилетов Аэрофлота. Но, к сожалению, ожидаемого коммерческого успеха машина не имела. Выпуск составил всего 28 ЭВМ, что совершенно не соответствовало возможностям завода им. Г. К. Орджоникидзе. Главными причинами неудачи этой ЭВМ, видимо, нужно считать непривычность для пользователя ее основных концепций, отсутствие совместимости с предыдущей моделью, недостаточную производительность на задачах научно-технического характера и не развившуюся еще у предприятий и организаций потребность в обработке деловой информации.
П.З.> Вот пусть эти "одну-две лишние операции" процессор и делает.
П.З.> И мне пофик как.
Он и будет их делать если написать на Паскале
например ввести
var myArray array [1..100] of char
и потом по индексу ходить, а код будет всякие битовые маски делать, ну потому что по-другому никак.
П.З.> У меня в "системе команд" должны быть инструкции с байтовой адресацией.
Если на Паскале писать в общем не так чтобы нужно
но вот про всякие С типа
char* p;
p++;
можно забыть. А вместе с ними про всякие awk, sed и прочие Perl, которые как раз и возникли от легкости работы с байтовыми указателями.
П.З.> И мне пофик как.
Он и будет их делать если написать на Паскале
например ввести
var myArray array [1..100] of char
и потом по индексу ходить, а код будет всякие битовые маски делать, ну потому что по-другому никак.
П.З.> У меня в "системе команд" должны быть инструкции с байтовой адресацией.
Если на Паскале писать в общем не так чтобы нужно
но вот про всякие С типа
char* p;
p++;
можно забыть. А вместе с ними про всякие awk, sed и прочие Perl, которые как раз и возникли от легкости работы с байтовыми указателями.
Татарин
П.З.> недостаточную производительность на задачах научно-технического характера и не развившуюся еще у предприятий и организаций потребность в обработке деловой информации.
Ну да.
Вот лет через 10-15 всё изменится. Но лет через 10-15 и линейка с потомками БЭСМ выглядела бы уже иначе, органично развиваясь в соотвествии с требованиями момента. Она выглядела так, как выглядела потому, что создавалась под требования начала-середины 60-х годов, где - пакетный режим, максимальная производительность на вещественных числах, минимум управляющих и текстовых задач.
Ну да.
Вот лет через 10-15 всё изменится. Но лет через 10-15 и линейка с потомками БЭСМ выглядела бы уже иначе, органично развиваясь в соотвествии с требованиями момента. Она выглядела так, как выглядела потому, что создавалась под требования начала-середины 60-х годов, где - пакетный режим, максимальная производительность на вещественных числах, минимум управляющих и текстовых задач.
yacc> но вот про всякие С типа
yacc> char* p;
yacc> p++;
Про char* p - конечно. А вот нативный тип наподобие alfa напрашивается, и инструментарий для работы с ним тоже. Появился же в С инструментарий работы с произвольными битовыми полями в составе union? Ну и для нативного типа alfa был бы инструментарий обращения к конкретному байту.
Тем более, как уже не раз сказано, для аппаратной поддержки подобного не нужно ничего кроме пары инструкций чтения/сохранения.
Твоя беда в том, что ты, рассуждая об альтернативе, парадоксально отрицаешь возможность альтернатив в принципе, и эта внутренняя логическая противоречивость - твоя отправная точка.
У тебя все мысли крутятся от актуального положения, которое сложилось во многом случайно. Ну а поскольку при любом изменении в прошлом текущий набор на нынешний момент инструментов становится другим, тебя, в силу недостатка кругозора, это вгоняет в ступор.
yacc> можно забыть. А вместе с ними про всякие awk, sed и прочие Perl, которые как раз и возникли от легкости работы с байтовыми указателями.
Конечно, они возникли не от этого... ну а такой работе со строками есть масса альтернатив. Впрочем, вполне возможно, что при аппаратной поддержке работы со строками, очень многие вещи, скрипты включая, выглядели бы иначе. Системы с аппаратным ускорением формирования XML/HTML показывают, что и как могло бы быть.
yacc> char* p;
yacc> p++;
Про char* p - конечно. А вот нативный тип наподобие alfa напрашивается, и инструментарий для работы с ним тоже. Появился же в С инструментарий работы с произвольными битовыми полями в составе union? Ну и для нативного типа alfa был бы инструментарий обращения к конкретному байту.
Тем более, как уже не раз сказано, для аппаратной поддержки подобного не нужно ничего кроме пары инструкций чтения/сохранения.
Твоя беда в том, что ты, рассуждая об альтернативе, парадоксально отрицаешь возможность альтернатив в принципе, и эта внутренняя логическая противоречивость - твоя отправная точка.
У тебя все мысли крутятся от актуального положения, которое сложилось во многом случайно. Ну а поскольку при любом изменении в прошлом текущий набор на нынешний момент инструментов становится другим, тебя, в силу недостатка кругозора, это вгоняет в ступор.
yacc> можно забыть. А вместе с ними про всякие awk, sed и прочие Perl, которые как раз и возникли от легкости работы с байтовыми указателями.
Конечно, они возникли не от этого... ну а такой работе со строками есть масса альтернатив. Впрочем, вполне возможно, что при аппаратной поддержке работы со строками, очень многие вещи, скрипты включая, выглядели бы иначе. Системы с аппаратным ускорением формирования XML/HTML показывают, что и как могло бы быть.
П.З.> У меня в "системе команд" должны быть инструкции с байтовой адресацией.
Зачем именно адресацией? и почему именно байтовой?
Представим себе, что у меня в аппаратуре есть команда выборки типа классической выборки по базе со смещением, но с дополнительным параметром - размерность операнда (что-то похожее, но внутри регистра, есть в большинстве развитых векторных наборов).
Ну, типа
mov r1, [r2 + r3:8] - то есть, взять базовый адрес r2, а от базового адреса выбрать байт с номером r3.
Чем это хуже?
Когда касается обработки именно байт...
С точки программиста - ничем. С точки железа - всё даже лучше.
Но всё гораздо интереснее становится при обработке более сложных структур (в том числе векторной).
Зачем именно адресацией? и почему именно байтовой?
Представим себе, что у меня в аппаратуре есть команда выборки типа классической выборки по базе со смещением, но с дополнительным параметром - размерность операнда (что-то похожее, но внутри регистра, есть в большинстве развитых векторных наборов).
Ну, типа
mov r1, [r2 + r3:8] - то есть, взять базовый адрес r2, а от базового адреса выбрать байт с номером r3.
Чем это хуже?
Когда касается обработки именно байт...
С точки программиста - ничем. С точки железа - всё даже лучше.
Но всё гораздо интереснее становится при обработке более сложных структур (в том числе векторной).
yacc> ... и внезапно там увидим байты... ага с системы 360, а не 48-битные слова как БЭСМ или 60 битные как у CDC.
В инструкциях сохранения/чтения, как дань традиции. То есть, та фигня, которая приделывается (и как мы знаем из реальности - и приделывалось) на пол-щелчка.
yacc> И читай эскизный проект БЭСМ-10 - нет там никаких байтов и байтовой адресации.
А причём тут вообще БЭСМ-10?
Мы же обсуждаем вариант, при котором в 1967-м архитектура и система команд БЭСМ-6 становится базовой для советской индустрии.
yacc> yacc>> Бухгалтерам нужен по факту Эксель.
Татарин>> Сомнительное утверждение, но...
Татарин>> В 60-х? ТОЧНО нет. И ещё очень долго нет.
yacc> И в 60!
Не пори чуши, а? До Экселя или хотя бы СуперКалька (именно вот с их отличительными особенностями, что и делает их Экселем и Суперкальком) - ещё лет 20 непрерывного интенсивного развития. Собссно, на тот момент тебя бы бухгалтера не поняли.
yacc> Тупая задача массового счета по вводным данным и простым формулам.
yacc> Часть задач вообще табуляторы тогда делали.
Именно так. И с этой задачей БЭСМ справляются отлично.
yacc> Это у ТЕБЯ их нет - ты же это реализовывать не собираешься.
Я ведь могу и реализовать. Не то, чтобы я гений цифровой схемотехники и великий знаток Верилога, но задача реально простая, доступная любителю.
yacc> Это тебе, зумеру - тяп-ляп и готово!
Это у тебя "тяп-ляп". А при спокойной, надёжной работе на это уходят первые месяцы у пары человек.
Ты взял очень милую привычку как-то забывать, что ты отстаиваешь альтернативу этой работе (на несколько человеко-месяцев) - а именно: многие тысячи (а скорее - десятки тысяч, судя по срокам из нашей реальности) человеко-лет на клонирование ИБМ/360.
yacc> Очевидно что Лебедев и Бурцев, в отличии от тебя, были реалистами.
И были категорически против ЕС.
yacc> Эльбрус выжил благодаря Бабаяну.
А ЕС не выжил не смотря ни на что. Несмотря на то, что это была сверхраспространённая архитектура в огромной стране - 17000 машин, десятки НИИ, дысятки-сотни тысяч человек знакомых с архитектурой как пользователи, разработчики, программисты.
yacc> И да - даже сейчас для бухгалтеров он избыточен.
Он прекрасно работает у бухгалтеров без всякой избыточности.
yacc> У тебя даже не научная фантастика
У меня даже фантастики нет. Я говорю-то даже только о том, что УЖЕ было в нашей реальности.
Если рассматривать то, что могло бы быть в СССР - см. разработки по тому РЕФАЛу или ранним работам по нейроморфным вычислениям в 70-х.
А ты защищаешь тупость. Просто на том основании, что это же тупо.
А значит, альтернатива должна быть умнее, а вот что-то умнее это уже нереально для СлавыКПСС.
В принципе, ход рассуждений понятен и даже в чём-то верен, но страна-то состояла не только из коммунистов. Были и те, кто работал.
В инструкциях сохранения/чтения, как дань традиции. То есть, та фигня, которая приделывается (и как мы знаем из реальности - и приделывалось) на пол-щелчка.
yacc> И читай эскизный проект БЭСМ-10 - нет там никаких байтов и байтовой адресации.
А причём тут вообще БЭСМ-10?
Мы же обсуждаем вариант, при котором в 1967-м архитектура и система команд БЭСМ-6 становится базовой для советской индустрии.
yacc> yacc>> Бухгалтерам нужен по факту Эксель.
Татарин>> Сомнительное утверждение, но...
Татарин>> В 60-х?
ТОЧНО нет. И ещё очень долго нет. yacc> И в 60!
Не пори чуши, а? До Экселя или хотя бы СуперКалька (именно вот с их отличительными особенностями, что и делает их Экселем и Суперкальком) - ещё лет 20 непрерывного интенсивного развития. Собссно, на тот момент тебя бы бухгалтера не поняли.
yacc> Тупая задача массового счета по вводным данным и простым формулам.
yacc> Часть задач вообще табуляторы тогда делали.
Именно так. И с этой задачей БЭСМ справляются отлично.
yacc> Это у ТЕБЯ их нет - ты же это реализовывать не собираешься.
Я ведь могу и реализовать. Не то, чтобы я гений цифровой схемотехники и великий знаток Верилога, но задача реально простая, доступная любителю.yacc> Это тебе, зумеру - тяп-ляп и готово!
Это у тебя "тяп-ляп".
А при спокойной, надёжной работе на это уходят первые месяцы у пары человек. Ты взял очень милую привычку как-то забывать, что ты отстаиваешь альтернативу этой работе (на несколько человеко-месяцев) - а именно: многие тысячи (а скорее - десятки тысяч, судя по срокам из нашей реальности) человеко-лет на клонирование ИБМ/360.
yacc> Очевидно что Лебедев и Бурцев, в отличии от тебя, были реалистами.
И были категорически против ЕС.
yacc> Эльбрус выжил благодаря Бабаяну.
А ЕС не выжил не смотря ни на что. Несмотря на то, что это была сверхраспространённая архитектура в огромной стране - 17000 машин, десятки НИИ, дысятки-сотни тысяч человек знакомых с архитектурой как пользователи, разработчики, программисты.
yacc> И да - даже сейчас для бухгалтеров он избыточен.
Он прекрасно работает у бухгалтеров без всякой избыточности.
yacc> У тебя даже не научная фантастика
У меня даже фантастики нет. Я говорю-то даже только о том, что УЖЕ было в нашей реальности.
Если рассматривать то, что могло бы быть в СССР - см. разработки по тому РЕФАЛу или ранним работам по нейроморфным вычислениям в 70-х.
А ты защищаешь тупость. Просто на том основании, что это же тупо.
А значит, альтернатива должна быть умнее, а вот что-то умнее это уже нереально для СлавыКПСС.
В принципе, ход рассуждений понятен и даже в чём-то верен, но страна-то состояла не только из коммунистов. Были и те, кто работал.
Татарин> Про char* p - конечно. А вот нативный тип наподобие alfa напрашивается, и инструментарий для работы с ним тоже. Появился же в С инструментарий работы с произвольными битовыми полями в составе union? Ну и для нативного типа alfa был бы инструментарий обращения к конкретному байту.
Татарин> Тем более, как уже не раз сказано, для аппаратной поддержки подобного не нужно ничего кроме пары инструкций чтения/сохранения.
Вообще-то на Паскале есть record который допускает работу с аналогом union, но у тебя варианта ровно два:
- либо ты по-простому индексируешь массив char и производишь операции по нему, т.е. простой код
- либо ты используешь трюки с alfa что как бы быстрее но код гораздо сложнее
Внимание, это в прикладной программе! Я про код на Паскале.
И в первом случае на БЭСМ ты имеешь что-то типа такого когда Паскаль это превратит в машкод
Это примерный аналог того, что будет если идти тупо по индексу. Я упростил и не взял вычисление поиска нужной alfa, т.е. адреса начала слова с символами, по idx.
Но даже тут все понятно:
у БЭСМ нет регистров как в 360 или в PDP-11 или в х86. Там есть только аккумулятор, операции с которым, типа сложения, выполняются указывая второй адрес в ОЗУ, либо напрямую либо через индексные регистры.
Обращение к памяти сразу съедает у тебя скорость.
В случае адресации байтов, достаточно взять адрес строки, сделать смещение в РОН на индекс и далее взять в другой РОН байт по одному адресу ( обращение к ОЗУ ), во второй взять байт по адресу базы ( обращение к ОЗУ ) и сравнить два РОН.
Два обращения к ОЗУ и никаких битовых масок!
А во-втором случае с хитрыми трюками с alfa это неподъемно для средней тетки-бухгалтера-программиста.
В итоге - выберут первый и машина будет работать... со скоростью Минск-32.
Татарин> Твоя беда в том, что ты, рассуждая об альтернативе, парадоксально отрицаешь возможность альтернатив в принципе, и эта внутренняя логическая противоречивость - твоя отправная точка.
Я не против обоснованных альтернатив.
Но ты их не показываешь, а уперся в БЭСМ-6. Причем даже не посмотрел что там все вокруг аккумулятора и ОЗУ крутится.
Ну не прижились нигде машины с адресацией длинных слов!
Объективное это то, что удобно пользователям независимо от случаев - в СССР или в США.
Но ты не приводишь объективных доказательств! - только "заговор" ЦРУ в США для CDC или "заговор" СлаваКПСС в СССР.
Если человек ссылается на "заговоры" то это к фентези, а не к обоснованной альтернативе.
Татарин> Тем более, как уже не раз сказано, для аппаратной поддержки подобного не нужно ничего кроме пары инструкций чтения/сохранения.
Вообще-то на Паскале есть record который допускает работу с аналогом union, но у тебя варианта ровно два:
- либо ты по-простому индексируешь массив char и производишь операции по нему, т.е. простой код
- либо ты используешь трюки с alfa что как бы быстрее но код гораздо сложнее
Внимание, это в прикладной программе! Я про код на Паскале.
И в первом случае на БЭСМ ты имеешь что-то типа такого когда Паскаль это превратит в машкод
section .bitMask
mask word 0000000 0000000 0000000 0000000 0000000 1111111 000000
word 0000000 0000000 0000000 0000000 1111111 0000000 000000
word 0000000 0000000 0000000 1111111 0000000 0000000 000000
section .shifts
shft word 0x000000000000 ; сдвиг на 0 позиций
word 0x000000000007 ; сдвиг на 7 позиций
word 0x00000000000e ; сдвиг на 7+7=14 позиций
section .data
val word 0000111 0000110 0000101 0000011 0000010 0000001 000000 ; слово 'аbcdef'
bas word 0000000 0000000 0000000 0000000 0000000 0000001 000000 ; буква 'а'
section .var
idx word 0x000000000002 ; индекс 2 ( третья буква )
; нам надо проверить что третья буква в слове val такая же как в bas
set idx1, mask ; заносим в первый индекс регистр адрес маски
; команда УИ БЭСМ ( адрес прямо в команде, нет обращения к ОЗУ )
set idx2, shft ; заносим во второй индекс регистр адрес сдвигов
; команда УИ БЭСМ ( адрес прямо в команде, нет обращения к ОЗУ )
add idx1, @idx ; увеличиваем первый индекс на смещение с величиной по адресу
; команда СИ БЭСМ - РАБОТА С ОЗУ!
add idx2, @idx ; увеличиваем второй индекс на смещение с величиной по адресу
; команда СИ БЭСМ - РАБОТА С ОЗУ!
ld @val ; заносим в сумматор ( аккумулятор ) величину строки
; команда СЧ БЭСМ - РАБОТА С ОЗУ!
and idx1 ; логическое AND сумматора с величиной по адресу в индексном регистре 1
; это мы выделяем третий символ
; команда ЛУ БЭСМ - РАБОТА С ОЗУ!
shr idx2 ; сдвиг сумматора на величину по адресу в индексном регистре 2
; символ сдвинут, его надо привести к сравнимому виду
; команда СД БЭСМ - РАБОТА С ОЗУ!
jcmp bas [адрес куда надо] ; сравнение сумматора с символом и переход
; команда УО БЭСМ - РАБОТА С ОЗУ!
Это примерный аналог того, что будет если идти тупо по индексу. Я упростил и не взял вычисление поиска нужной alfa, т.е. адреса начала слова с символами, по idx.
Но даже тут все понятно:
у БЭСМ нет регистров как в 360 или в PDP-11 или в х86. Там есть только аккумулятор, операции с которым, типа сложения, выполняются указывая второй адрес в ОЗУ, либо напрямую либо через индексные регистры.
Обращение к памяти сразу съедает у тебя скорость.
В случае адресации байтов, достаточно взять адрес строки, сделать смещение в РОН на индекс и далее взять в другой РОН байт по одному адресу ( обращение к ОЗУ ), во второй взять байт по адресу базы ( обращение к ОЗУ ) и сравнить два РОН.
Два обращения к ОЗУ и никаких битовых масок!
А во-втором случае с хитрыми трюками с alfa это неподъемно для средней тетки-бухгалтера-программиста.
В итоге - выберут первый и машина будет работать... со скоростью Минск-32.
Татарин> Твоя беда в том, что ты, рассуждая об альтернативе, парадоксально отрицаешь возможность альтернатив в принципе, и эта внутренняя логическая противоречивость - твоя отправная точка.
Я не против обоснованных альтернатив.
Но ты их не показываешь, а уперся в БЭСМ-6. Причем даже не посмотрел что там все вокруг аккумулятора и ОЗУ крутится.
Ну не прижились нигде машины с адресацией длинных слов!
Объективное это то, что удобно пользователям независимо от случаев - в СССР или в США.
Но ты не приводишь объективных доказательств! - только "заговор" ЦРУ в США для CDC или "заговор" СлаваКПСС в СССР.
Если человек ссылается на "заговоры" то это к фентези, а не к обоснованной альтернативе.
Это сообщение редактировалось 06.01.2024 в 01:18
yacc>> И читай эскизный проект БЭСМ-10 - нет там никаких байтов и байтовой адресации.
Татарин> А причём тут вообще БЭСМ-10?
Татарин> Мы же обсуждаем вариант, при котором в 1967-м архитектура и система команд БЭСМ-6 становится базовой для советской индустрии.
А потому что Лебедев, т.е. конструктор БЭСМ-6.
Причем реальный Лебедев.
Реальному Лебедеву были интересны высокопроизводительные вычисления, в том числе параллельные.
Это только тебе приходит в голову ввести фантастического Лебедева, который бы бросил все эти скорости и начал бы делать БЭСМ-6 для бухгалтеров. Я даже боюсь представить что надо с ним было сделать чтобы выбить из него тягу к скорости и заставить работать над "бытовухой".
ИМиВТ - это кузница скоростных машин. Типа фирмы Феррари.
И тут к нему приходят и говорят - а давай-ка Феррари ты забудешь что там условно Порше(СDC) работает сейчас над более скоростными болидами, уберешь нафиг свои стремления сделать свои болиды быстрее и сделаешь нам массовый Ситроен 2CV из своего болида(БЭСМ-6).
Такое фентези только тебе в голову пришло!
Татарин> Не пори чуши, а? До Экселя или хотя бы СуперКалька (именно вот с их отличительными особенностями, что и делает их Экселем и Суперкальком) - ещё лет 20 непрерывного интенсивного развития.
Только он делает ту же рутину что и табуляторы раньше, а потом Мински.
yacc>> Часть задач вообще табуляторы тогда делали.
Татарин> Именно так. И с этой задачей БЭСМ справляются отлично.
Ты Иву не услышал, хотя он прямым текстом все правильно сказал.
yacc>> Это у ТЕБЯ их нет - ты же это реализовывать не собираешься.
Татарин> Я ведь могу и реализовать. Не то, чтобы я гений цифровой схемотехники и великий знаток Верилога, но задача реально простая, доступная любителю.
Т.е. процессор БЭСМ-6 в 1967 году делали не профессионалы в электронике и схемотехнике, а любители ?
Вот это поворот!
Татарин> Это у тебя "тяп-ляп". А при спокойной, надёжной работе на это уходят первые месяцы у пары человек.
Чего ???
Татарин> Ты взял очень милую привычку как-то забывать, что ты отстаиваешь альтернативу этой работе (на несколько человеко-месяцев) - а именно: многие тысячи (а скорее - десятки тысяч, судя по срокам из нашей реальности) человеко-лет на клонирование ИБМ/360.
Ты забываешь что разработка и доводка схемотехники ЭВМ в 60-е это сотни человеко-месяцев.
На простую байтовую адресацию.
Это ТЕБЕ легко в 21 веке, но переносить трудоемкость 21 века на 60-е года 20 века - это за гранью!!!
yacc>> Очевидно что Лебедев и Бурцев, в отличии от тебя, были реалистами.
Татарин> И были категорически против ЕС.
Как раз в качестве массовой они и не были против.
Татарин> А ЕС не выжил не смотря ни на что.
Так и мейнфреймы IBM стали нишевыми.
Просто у нас ЕС заменили на IBM где миграция и железо были критичны.
yacc>> И да - даже сейчас для бухгалтеров он избыточен.
Татарин> Он прекрасно работает у бухгалтеров без всякой избыточности.
Он у них НЕ работает.
Татарин> Если рассматривать то, что могло бы быть в СССР - см. разработки по тому РЕФАЛу или ранним работам по нейроморфным вычислениям в 70-х.
РЕФАЛ это для гиков.
Татарин> А ты защищаешь тупость.
Я не пытаюсь представить что все программисты могут быть сеньорами и олимпиадниками.
Я смотрю на вещи реально.
Татарин> А причём тут вообще БЭСМ-10?
Татарин> Мы же обсуждаем вариант, при котором в 1967-м архитектура и система команд БЭСМ-6 становится базовой для советской индустрии.
А потому что Лебедев, т.е. конструктор БЭСМ-6.
Причем реальный Лебедев.
Реальному Лебедеву были интересны высокопроизводительные вычисления, в том числе параллельные.
Это только тебе приходит в голову ввести фантастического Лебедева, который бы бросил все эти скорости и начал бы делать БЭСМ-6 для бухгалтеров. Я даже боюсь представить что надо с ним было сделать чтобы выбить из него тягу к скорости и заставить работать над "бытовухой".
ИМиВТ - это кузница скоростных машин. Типа фирмы Феррари.
И тут к нему приходят и говорят - а давай-ка Феррари ты забудешь что там условно Порше(СDC) работает сейчас над более скоростными болидами, уберешь нафиг свои стремления сделать свои болиды быстрее и сделаешь нам массовый Ситроен 2CV из своего болида(БЭСМ-6).
Такое фентези только тебе в голову пришло!
Татарин> Не пори чуши, а? До Экселя или хотя бы СуперКалька (именно вот с их отличительными особенностями, что и делает их Экселем и Суперкальком) - ещё лет 20 непрерывного интенсивного развития.
Только он делает ту же рутину что и табуляторы раньше, а потом Мински.
yacc>> Часть задач вообще табуляторы тогда делали.
Татарин> Именно так. И с этой задачей БЭСМ справляются отлично.
Ты Иву не услышал, хотя он прямым текстом все правильно сказал.
yacc>> Это у ТЕБЯ их нет - ты же это реализовывать не собираешься.
Татарин>
Я ведь могу и реализовать. Не то, чтобы я гений цифровой схемотехники и великий знаток Верилога, но задача реально простая, доступная любителю.Т.е. процессор БЭСМ-6 в 1967 году делали не профессионалы в электронике и схемотехнике, а любители ?
Вот это поворот!
Татарин> Это у тебя "тяп-ляп".
А при спокойной, надёжной работе на это уходят первые месяцы у пары человек. Чего ???
Татарин> Ты взял очень милую привычку как-то забывать, что ты отстаиваешь альтернативу этой работе (на несколько человеко-месяцев) - а именно: многие тысячи (а скорее - десятки тысяч, судя по срокам из нашей реальности) человеко-лет на клонирование ИБМ/360.
Ты забываешь что разработка и доводка схемотехники ЭВМ в 60-е это сотни человеко-месяцев.
На простую байтовую адресацию.
Это ТЕБЕ легко в 21 веке, но переносить трудоемкость 21 века на 60-е года 20 века - это за гранью!!!
yacc>> Очевидно что Лебедев и Бурцев, в отличии от тебя, были реалистами.
Татарин> И были категорически против ЕС.
Как раз в качестве массовой они и не были против.
Татарин> А ЕС не выжил не смотря ни на что.
Так и мейнфреймы IBM стали нишевыми.
Просто у нас ЕС заменили на IBM где миграция и железо были критичны.
yacc>> И да - даже сейчас для бухгалтеров он избыточен.
Татарин> Он прекрасно работает у бухгалтеров без всякой избыточности.
Он у них НЕ работает.
Татарин> Если рассматривать то, что могло бы быть в СССР - см. разработки по тому РЕФАЛу или ранним работам по нейроморфным вычислениям в 70-х.
РЕФАЛ это для гиков.
Татарин> А ты защищаешь тупость.
Я не пытаюсь представить что все программисты могут быть сеньорами и олимпиадниками.
Я смотрю на вещи реально.
yacc> Что там было в 90-е со SCSI RAID под ISA ?
Именно аппаратный SCSI RAID Не помню, а просто SCSI вполне. Только скорее EISA, не помню уже за давностью лет - середина 90-х. Т.ч. софтовый RAID вполне себе, как минимум. С аппаратным уже PCI, но оно тоже уже в 90-х было.
yacc> И какая ОСь это видела ?
Нетварь, NT начиная с 3.5. С 3.1 дела не имел.
Именно аппаратный SCSI RAID Не помню, а просто SCSI вполне. Только скорее EISA, не помню уже за давностью лет - середина 90-х. Т.ч. софтовый RAID вполне себе, как минимум. С аппаратным уже PCI, но оно тоже уже в 90-х было.
yacc> И какая ОСь это видела ?
Нетварь, NT начиная с 3.5. С 3.1 дела не имел.
yacc>> Что там было в 90-е со SCSI RAID под ISA ?
imaex> Именно аппаратный SCSI RAID Не помню, а просто SCSI вполне.
адаптековские скази контроллеры под ISA точно были, и с рейдом и без, самый шик был что бы рейд и с батарейкой для кэша.
на FreeBSD и NTшке их пользовал.
с дровами там магия была ещё та.
и диски и кабеля с дейзичейнм стоили просто мама не горюй, и разновидностей их было..узкие, широкие, второй скази, третий...с встроенным терминатором, с внешним...
imaex> Именно аппаратный SCSI RAID Не помню, а просто SCSI вполне.
адаптековские скази контроллеры под ISA точно были, и с рейдом и без, самый шик был что бы рейд и с батарейкой для кэша.
на FreeBSD и NTшке их пользовал.
с дровами там магия была ещё та.
и диски и кабеля с дейзичейнм стоили просто мама не горюй, и разновидностей их было..узкие, широкие, второй скази, третий...с встроенным терминатором, с внешним...
с.т.> адаптековские скази контроллеры под ISA точно были
Я только про то, с чем сам дело имел. Насчёт исы засомневался из-за пропускной способности шины.
с.т.> с дровами там магия была ещё та.
Да в NT особой магии не было, а вот в нетвари 1.х - эт точно. Там вроде только в 2.20 уже не нужно было ядро собирать из объектников.
Я только про то, с чем сам дело имел. Насчёт исы засомневался из-за пропускной способности шины.
с.т.> с дровами там магия была ещё та.
Да в NT особой магии не было, а вот в нетвари 1.х - эт точно. Там вроде только в 2.20 уже не нужно было ядро собирать из объектников.
imaex> Именно аппаратный SCSI RAID Не помню, а просто SCSI вполне.
Просто SCSI это неинтересно.
imaex>Только скорее EISA, не помню уже за давностью лет - середина 90-х.
Ну т.е. порядка 10 лет после выхода 386
Просто SCSI это неинтересно.
imaex>Только скорее EISA, не помню уже за давностью лет - середина 90-х.
Ну т.е. порядка 10 лет после выхода 386
Татарин> Ну, типа
Татарин> mov r1, [r2 + r3:8] - то есть, взять базовый адрес r2, а от базового адреса выбрать байт с номером r3.
Татарин> Чем это хуже?
Это намного хуже
Именно это вот и есть ЗЛО
Татарин> mov r1, [r2 + r3:8] - то есть, взять базовый адрес r2, а от базового адреса выбрать байт с номером r3.
Татарин> Чем это хуже?
Это намного хуже
Именно это вот и есть ЗЛО
yacc> но вот про всякие С типа
yacc> char* p;
yacc> p++;
yacc> можно забыть. А вместе с ними про всякие awk, sed и прочие Perl, которые как раз и возникли от легкости работы с байтовыми указателями.
Новосибирцы в своё время портировали Unix на БЭСМ-6, даже не на СВС. Работало нормально вполне. Наибольшая проблема была в том, что периферия не показывала маленькие латинские буквы. Единственный подходящий терминал был "Фрязинский дисплей", а для распечаток ДЗМ.
yacc> char* p;
yacc> p++;
yacc> можно забыть. А вместе с ними про всякие awk, sed и прочие Perl, которые как раз и возникли от легкости работы с байтовыми указателями.
Новосибирцы в своё время портировали Unix на БЭСМ-6, даже не на СВС. Работало нормально вполне. Наибольшая проблема была в том, что периферия не показывала маленькие латинские буквы. Единственный подходящий терминал был "Фрязинский дисплей", а для распечаток ДЗМ.
yacc> Это только тебе приходит в голову ввести фантастического Лебедева, который бы бросил все эти скорости и начал бы делать БЭСМ-6 для бухгалтеров. Я даже боюсь представить что надо с ним было сделать чтобы выбить из него тягу к скорости и заставить работать над "бытовухой".
Передали бы во ВНИИЦЭВТ и вся недолга.
И это я ещё на твоей стороне. ЕС однозначно был прогресс а ув. Татарин заблуждается. Но твои аргументы нужно подтянуть. Оставь байтовые операции и душу С.А.Лебедева в покое.
Передали бы во ВНИИЦЭВТ и вся недолга.
И это я ещё на твоей стороне. ЕС однозначно был прогресс а ув. Татарин заблуждается. Но твои аргументы нужно подтянуть. Оставь байтовые операции и душу С.А.Лебедева в покое.
П.З.> Именно это вот и есть ЗЛО
Какое же это зло?
Зло бывает в намерениях.
Зло бывает в неумеренности.
Зло бывает от непонимания.
А тут всего-то перевод алгоритма на "промежуточный" язык. Который хоть как-то понимает человек и как-то понимает машина. Ну, после перевода с этой мовы в родные машкоды.
Какое же это зло?
Зло бывает в намерениях.
Зло бывает в неумеренности.
Зло бывает от непонимания.
А тут всего-то перевод алгоритма на "промежуточный" язык. Который хоть как-то понимает человек и как-то понимает машина. Ну, после перевода с этой мовы в родные машкоды.
Copyright © Balancer 1997..2026
Создано 15.02.2023
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 15.02.2023
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
