История отрасли вообще знает примеры, чтобы язык взял и перестал использоваться? (*) У меня есть ощущение, что язык может умереть только вместе с платформой, например или APL, PL/I. Пока жива платформа, где этот язык был распространён, язык тоже живет (Cobol, Fortran) и уменьшение использования связано только с уменьшением использования платформы.
Соответственно, темы, вроде соседней, просто не имеют смысла. Пока x86 жива и используется, .Net, C++, C, Java и прочие никуда не денутся.
На мой взгляд технология умирает, когда её перестают применять в новых проектах (в заметном количестве). По этому параметру Cobol умер, Delphi умерло, например. .NET, Java, C++ живей всех живых.
А если просто смотреть на то, есть ли где-то запущенный код, то и через 100 лет будет кобол где-нибудь работать.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, bzig, Вы писали:
B>>Навеяно соседней темой. B>>История отрасли вообще знает примеры, чтобы язык взял и перестал использоваться?
S>Ассемблеры вместе с аппаратурой, наверное, да и всё.
Ассемблер, возможно, неплохой пример, но был ли он когда-нибудь популярным? Брэйнфак, например, не используется, но он и популярным не был.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, bzig, Вы писали:
B>>Ну. Так зачем тогда заводить темы "XXX всё".
vsb>Чтобы люди не тратили время на изучение мёртвых технологий.
Это в обе стороны работает — если они потратят время на изучение, то технология не будет мертвой
S>>В древние времена был. Выбор-то был между ассемблером и бейсиком.
B>Это на какой платформе выбор был между бэйсиком и ассемблером? На Спектруме? Ну так Спектруме они и остались, туда вроде других языков не завезли.
Здравствуйте, bzig, Вы писали:
B>Ассемблер, возможно, неплохой пример, но был ли он когда-нибудь популярным? Брэйнфак, например, не используется, но он и популярным не был.
На ЕС ЭВМ Ассемблер был довольно популярен. Тогда тоже нехилые войны шли: Ассемблер vs Фортран, Ассемблер vs PL/1. Мне старшие товарищи говорили.
Сам же я успел увидеть, что некоторые насквозь прикладные программы сделаны на Ассемблере. Мне библиотеку исходников показывали.
Помню случай. Одна из этих программа чего-то там формировала и работала от полутора до трех часов. В зависимости от типа ЭВМ. На Ес-1033 дольше, на ЕС-1036 — меньше. В какой-то момент пришла новая версия того пакета, и программа стала работать от десятков секунд до пары минут.
Еще пытались продвигать PL/1. Говорили, что в СССР он был намного популярнее, чем на западе. Даже я разок столкнулся. Я как-то рассказывал про грузинские идентификаторы в программе. Мой первый выговор. Но сейчас Кобол есть, а PL/1 — не видно.
Здравствуйте, vsb, Вы писали:
vsb>По этому параметру Cobol умер, Delphi умерло, например. .NET, Java, C++ живей всех живых.
Я как-то видел Кобол для .Net. Умер, ага.
vsb>А если просто смотреть на то, есть ли где-то запущенный код, то и через 100 лет будет кобол где-нибудь работать.
Почему запущенный? Проекты на Коболе пилятся. Да, живут десятилетиями. Спецы, знающие Кобол, востребованы. Это называется умер?
Здравствуйте, Privalov, Вы писали:
P>Еще пытались продвигать PL/1. Говорили, что в СССР он был намного популярнее, чем на западе. Даже я разок столкнулся. Я как-то рассказывал про грузинские идентификаторы в программе. Мой первый выговор. Но сейчас Кобол есть, а PL/1 — не видно.
PL/1 был относительно неплохим языком. Да, нагромождение всех концепций известных к середине 60-х, но отсюда универсальность в сферах применения и свободный выбор способа написать программу. Возможность выстрелить себе в ногу на каждом шагу, но чем фортран был хуже в этом отношении
А Кобола у нас не было видно тогда (наверно за очень редкими исключениями) и тем более не видно сейчас.
Откуда там грузинские идентификаторы? Там же расширение 256 символьной таблицы использовалось. Наверно там где, были клавиатуры с грузинскими буквами, дисплеи и принтеры с грузинскими прошивками, могли быть и грузинские идентификаторы, но не уверен, русских идентификаторов там не видел, может никто и не пытался
Здравствуйте, pagid, Вы писали:
P>PL/1 был относительно неплохим языком. Да, нагромождение всех концепций известных к середине 60-х, но отсюда универсальность в сферах применения и свободный выбор способа написать программу. Возможность выстрелить себе в ногу на каждом шагу, но чем фортран был хуже в этом отношении
Граблей хватало как в Фортране, так и в Коболе. Их все перенесли в PL/1 и добавили свежих. Граблей в Фортране я и сейчас бы не испугался. А в PL/1 — боялся тогда. Сейчас, слава байту, его нет. Тогда больше учили, как не надо писать на Фортране. Набив немного шишек, грабди те обходил автоматом. И еще у Фортрана практически идеальная переносимость на уровне исходного кода.
Примерно половина служебных слов PL/1 вошла в современный английский язык. Плюс тормоза PL-ппрограммы по сравнению с такой же фортрановской.
P>Откуда там грузинские идентификаторы? Там же расширение 256 символьной таблицы использовалось. Наверно там где, были клавиатуры с грузинскими буквами, дисплеи и принтеры с грузинскими прошивками, могли быть и грузинские идентификаторы, но не уверен, русских идентификаторов там не видел, может никто и не пытался
Грузинские идентификаторы там прямо из Тбилиси.Латиницей
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, bzig, Вы писали:
B>>Ну. Так зачем тогда заводить темы "XXX всё".
vsb>Чтобы люди не тратили время на изучение мёртвых технологий.
Странные рассуждения...
В этих вот "мётрвых_технологиях" — есть всё, что есть в современных.
Так, например, изучив циклы на Паскале/Делфи — видишь, что они есть и в С/С++, и в Java, и в .NET, и в Python. Только некоторые синтаксические отличия.
Или то же ООП — инкапсуляция, наследование, полиморфизм — изучил я на примере C++. Дальше — нет проблем с пониманием этой концепции для .NET, Java и т.д.
Следует вывод:
Не спать в шапку, а изучать то — что имеется и востребовано сегодня!
Это станет для тебя базой и большим подспорьем завтра!
Здравствуйте, Privalov, Вы писали:
P>Граблей хватало как в Фортране, так и в Коболе. Их все перенесли в PL/1 и добавили свежих.
Свежих точно добавили, но с переносом есть сомнения, во всяком случае из Кобола наверно перенесли только типы данных принятые там и возможность легко работать с "наборами данных" (в смысле — файлами современным языком) в форматах принятых в Коболе.
P>Граблей в Фортране я и сейчас бы не испугался. А в PL/1 — боялся тогда.
Тогдашний фортран отдавал некоторой убогостью унаследованной из конца 50-х, в последующих стандартах может и причесали
P>И еще у Фортрана практически идеальная переносимость на уровне исходного кода.
Это от того, что он довольно таки специализированный язык, и простой конечно.
P>Примерно половина служебных слов PL/1 вошла в современный английский язык.
P>Плюс тормоза PL-ппрограммы по сравнению с такой же фортрановской.
Компилировался он точно медленней, пособирали туда всякого м сделали. А программа выполнялась... Фортран лучше поддается оптимизации, а самое главное в ПЛ легко можно наворотить всякого увеличивающего время исполнения в разы
P>Грузинские идентификаторы там прямо из Тбилиси.Латиницей
Здравствуйте, pagid, Вы писали:
P>Свежих точно добавили, но с переносом есть сомнения, во всяком случае из Кобола наверно перенесли только типы данных принятые там и возможность легко работать с "наборами данных" (в смысле — файлами современным языком) в форматах принятых в Коболе.
Ну да, структуры в PL/1 практически идентичны структурам Кобола. Практически — потому что я не помню, как в PL сдалали аналог RENAME и REDEFINE, и был ли он там вообще.
И что в OS/360 файлы и наборы данных — не одно и то же, я успел узнать. И не только в теории.
P>Тогдашний фортран отдавал некоторой убогостью унаследованной из конца 50-х, в последующих стандартах может и причесали
В Фортранек 4 я использовал в основном арифметический if. Чтобы goto не писать. В Фортране 77 появился нормальный if-then-else-endif, циклы while, switch case. В стандарте 90 появились размещаемые (allocatable) массивы, автоматические переменные. Чуть позже в нем поддержали рекурсию, но с этим я уже не работал.
P>>И еще у Фортрана практически идеальная переносимость на уровне исходного кода. P>Это от того, что он довольно таки специализированный язык, и простой конечно.
Я уже не помню, была ли там работа с битами, где можно было граблей словить. Я нарвался только на массивы, которые в MS DOS с конца сегмента переносились в начало. Лечилось проставлением атрибута HUGE.
А еще в Фортране можно было точно знать размеры переменных. В тех же Сях они от реализации зависят.
P>Компилировался он точно медленней, пособирали туда всякого м сделали. А программа выполнялась... Фортран лучше поддается оптимизации, а самое главное в ПЛ легко можно наворотить всякого увеличивающего время исполнения в разы
Матан на PL/1 тормозил. А что компилятор медленный, так то понятно. Он работал в 96 К памяти, был шестипроходным. Кстати, вот эти 96 К были серьезной преградой студентам, которые просили хотя бы 128 для своих задач. А чтобы еще больше, необходимо было разрешение начальника ВЦ.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, bzig, Вы писали:
B>>Ассемблер, возможно, неплохой пример, но был ли он когда-нибудь популярным? Брэйнфак, например, не используется, но он и популярным не был.
P>На ЕС ЭВМ Ассемблер был довольно популярен. Тогда тоже нехилые войны шли: Ассемблер vs Фортран, Ассемблер vs PL/1. Мне старшие товарищи говорили.
Ну это скорее подверждает мою мысль — популярный язык умирает только вместе с платформой. Ассемблер для Спектрума, Ассемблер для ЕС ЭВМ — оба померли с платформами.
А Ассемблер х86 особенно популярным и не был никогда.
P>Но сейчас Кобол есть,
Кобол есть на мэйнфрэймах, где он и был
P>а PL/1 — не видно.
Так ЕС ЭВМ помер.
P>Еще пытались продвигать PL/1. Говорили, что в СССР он был намного популярнее, чем на западе.
У нас в институте один препод был лютый фанатик PL/1 и пытался всех заразить. Лет за 10 до этого может и проканало бы, но мы все в институт уже пришли с опытом школьного программирования (Паскаль, Бэйсик, а у кого-то и С) и на их фоне PL/1 смотрелся каким-то недоразумением. При этом я не помню сейчас, был ли он вообще на PC (*) портирован.
Здравствуйте, bzig, Вы писали:
... B>А Ассемблер х86 особенно популярным и не был никогда.
В конце 80-х и начале 90-х он ещё как был у нас популярен!
Но — производительность аппаратной базы росла, и его вытеснили — сначала ANSI C, затем уже и C++
P.S. Я специально не упоминаю здесь .NET и Java — так как это уже совсем другая историятехнологическая ниша...
Здравствуйте, bzig, Вы писали:
B>Кобол есть на мэйнфрэймах, где он и был
Сталкивался. Точнее, как я уже писал раньше, мне вместо документации фрагменты data division присылали. Там нужные мне структуры были описаны.
B>Так ЕС ЭВМ помер.
А IBM/390 — вполне жив. И работает на нем очередная версия OS/360. И JCL на нем какой был, такой и остался. Я 390-ю машину живой не видел. Мне только документация на глаза попадалась.
B>У нас в институте один препод был лютый фанатик PL/1 и пытался всех заразить. Лет за 10 до этого может и проканало бы, но мы все в институт уже пришли с опытом школьного программирования (Паскаль, Бэйсик, а у кого-то и С) и на их фоне PL/1 смотрелся каким-то недоразумением. При этом я не помню сейчас, был ли он вообще на PC (*) портирован.
Тут на форуме коллега кт иногда про PL/1 статьи публикует. Еще раньше я читал в журналах, что PL/1 портировали на 80386, причем программы работали в 32-битовом реальном режиме. Типа для ускорения.
B>(*) IBM PC XT имеется ввиду, конечно
На XT я встречал какой-то PL/M, но есть ли у него что-то общее с PL/1, я не знаю. Синтаксис, вроде, похож.
Здравствуйте, AlexGin, Вы писали:
AG>В конце 80-х и начале 90-х он ещё как был у нас популярен! AG>Но — производительность аппаратной базы росла, и его вытеснили — сначала ANSI C, затем уже и C++
На ассемблере в MS DOS писали обработчики прерываний и резидентные программы. И вирусы, конечно. Второе и третье я не делал, а для первого использовал, как правило, встроенный ассемблер. А чтобы полностью проект далался на ассемблере, я такого не видел ни разу.
P>Тут на форуме коллега кт иногда про PL/1 статьи публикует. Еще раньше я читал в журналах, что PL/1 портировали на 80386, причем программы работали в 32-битовом реальном режиме. Типа для ускорения.
Караванов-то? У нас был аспирант Караванов, практические занятия вёл, как раз ученик того лютого препода. Не удивлюсь, что эти два Караванова — один человек
Здравствуйте, Privalov, Вы писали:
P>А еще в Фортране можно было точно знать размеры переменных. В тех же Сях они от реализации зависят.
Ну это только после того, как везде восторжествовал IEEE 754, а до того даже при одной разрядности слова могли отличаться длины мантиссы и порядка, правила нормализации и т.д. и можно было словить разное поведение на разных архитектурах, а уж когда и длины слова были разными
Здравствуйте, Privalov, Вы писали:
P>На XT я встречал какой-то PL/M, но есть ли у него что-то общее с PL/1, я не знаю. Синтаксис, вроде, похож.
Скорее несколько ключевых слов и традиция все писать прописными буквами.
Здравствуйте, pagid, Вы писали:
P>Ну это только после того, как везде восторжествовал IEEE 754, а до того даже при одной разрядности слова могли отличаться длины мантиссы и порядка, правила нормализации и т.д. и можно было словить разное поведение на разных архитектурах, а уж когда и длины слова были разными
А на ЕС ЭВМ он уже был? Я что-то не помню.
Признаться, я уже не помню деталей, как оно все было на ЕС ЭВМ. Я даже не помню, по каким стандартам в них представлялись вещественные числа. Я только знаю, что они были двух типов: real*4 и real*8, оно же double precision. При переносе с ЕС на PC никаких проблем с ними не возникло. На PC диапазон заметно шире. И про всякого рода грабли в Фортране столько всего уже тогда написано было, что многие нюансы учитывались автоматически.
Вот только производительности уже тогда старенькой "двойки" сильно не хватало. После десятков минут на ЕС-1036, на PC/AT оно считало, ну очень долго. А уже на "тройке" стало полегче. А когда появился 32-битовый компилятор, еще лучше. А еще позже у нас у каждого появился дома "Пентиум-90". Мы запускали нашу программу на конторской "двойке", чтобы присутствие на работе обозначить. А реальную работу делали на своей технике, под DESQView.
Здравствуйте, Privalov, Вы писали:
P>А на ЕС ЭВМ он уже был? Я что-то не помню. P>Признаться, я уже не помню деталей, как оно все было на ЕС ЭВМ. Я даже не помню, по каким стандартам в них представлялись вещественные числа. Я только знаю, что они были двух типов: real*4 и real*8, оно же double precision. При переносе с ЕС на PC никаких проблем с ними не возникло. На PC диапазон заметно шире. И про всякого рода грабли в Фортране столько всего уже тогда написано было, что многие нюансы учитывались автоматически.
Разные. На IBM/360 чуть по другому. Тоже одинарной и двойной точности — 4 и 8 байт, и это уже позволяет быть программам более-менее переносимыми, но представление другое и пределы в которых могут быть представлены числа другие. Еще могут быть разные реакции и разные моменты наступления особых ситуаций, наподобие потери значимости, но все же если не приближаться к пределам представления, то не должно быть особых проблем. Результаты расчетов будут не совсем одинаковыми, но программа будет переносимой.
P>Вот только производительности уже тогда старенькой "двойки" сильно не хватало. После десятков минут на ЕС-1036, на PC/AT оно считало, ну очень долго. А уже на "тройке" стало полегче. А когда появился 32-битовый компилятор, еще лучше. А еще позже у нас у каждого появился дома "Пентиум-90". Мы запускали нашу программу на конторской "двойке", чтобы присутствие на работе обозначить. А реальную работу делали на своей технике, под DESQView.
Ох не евреи вы похоже. Пару лет назад на воспоминания одного ссылку давали. Там все наоборот. В начале 70-х, подряжались расчеты делать, якобы вручную, и деньги получали как за ручные расчеты, в реальности считали на работе используя ЭВМ в личных целях. Местами занятные воспоминания, но автора так и прет от того, что он такой умный и хитрый и всю дорогу благодаря своему уму ништяки разные от жизни имел
P>Разные. На IBM/360 чуть по другому. Тоже одинарной и двойной точности — 4 и 8 байт, и это уже позволяет быть программам более-менее переносимыми, но представление другое и пределы в которых могут быть представлены числа другие.
Значения всех констант типа машинного эпсилон, минимум, максимум, мы знали. При переносе с ЕС на PC проблем не возникло. Вот если бы назад пришлось переносить, там могли нарваться. У PC с константами получше, чем у ЕС.
P>Ох не евреи вы похоже. Пару лет назад на воспоминания одного ссылку давали. Там все наоборот. В начале 70-х, подряжались расчеты делать, якобы вручную, и деньги получали как за ручные расчеты, в реальности считали на работе используя ЭВМ в личных целях. Местами занятные воспоминания, но автора так и прет от того, что он такой умный и хитрый и всю дорогу благодаря своему уму ништяки разные от жизни имел
Это значит, у него хорошие связи были на каком-нибудь ВЦ. Либо он сам там работал. Потому что машинное время тогда стоило недешево. Чтобы просто человек пришел и начал свои пакеты запускать — такого я не помню. Я в самом начале карьеры успел на таком ВЦ сменным инженером поработать. И видел, какие драки за машинное время устраивают на планерках.
И потом, в 70-е такое было прокручивать весьма непросто. Это в 90-е мы сами себе разработки продавали иногда.
Здравствуйте, Privalov, Вы писали:
P>>Ну это только после того, как везде восторжествовал IEEE 754, а до того даже при одной разрядности слова могли отличаться длины мантиссы и порядка, правила нормализации и т.д. и можно было словить разное поведение на разных архитектурах, а уж когда и длины слова были разными P>А на ЕС ЭВМ он уже был? Я что-то не помню.
Нет, конечно. Первые реализации в соответствии с ранними версиями IEEE754 это конец 70-х, а в линии S/360 он пришёл только в S/390.
Вообще во времена S/360 и 370 многое только отрабатывалось. В 1968-м IBM "отзывала" все свои машины на переделку, потому что при двойной точности у них даже guard bit в вычислениях не было! Минимальная тройка guard-round-sticky сложилась уже на основании разнообразного опыта.
P>Признаться, я уже не помню деталей, как оно все было на ЕС ЭВМ. Я даже не помню, по каким стандартам в них представлялись вещественные числа. Я только знаю, что они были двух типов: real*4 и real*8, оно же double precision. При переносе с ЕС на PC никаких проблем с ними не возникло. На PC диапазон заметно шире. И про всякого рода грабли в Фортране столько всего уже тогда написано было, что многие нюансы учитывались автоматически.
На PC диапазон у́же для single. IBM HFP (эта самая старая плавучка) оба single и double имеют максимумы около 7.2e75, но различается длина мантиссы. IEEE754 single до 3.4e38, то есть предел порядка в 2 раза меньше. Зато точность расчётов на IEEE754 сильно выше из-за отсутствия прыжков "следующий порядок => теряем сразу 4 бита точности".
P>Вот только производительности уже тогда старенькой "двойки" сильно не хватало. После десятков минут на ЕС-1036, на PC/AT оно считало, ну очень долго. А уже на "тройке" стало полегче. А когда появился 32-битовый компилятор, еще лучше. А еще позже у нас у каждого появился дома "Пентиум-90". Мы запускали нашу программу на конторской "двойке", чтобы присутствие на работе обозначить. А реальную работу делали на своей технике, под DESQView.
Ну чем там брала ЕС1036, не знаю, а по сравнению со всякими 1022 и 1033 писюки уже неплохо шли
Или эта ваша 286 была без сопроцессора? Тогда, конечно, ад и сектор Газа.
Здравствуйте, netch80, Вы писали:
N>На PC диапазон у́же для single. IBM HFP (эта самая старая плавучка) оба single и double имеют максимумы около 7.2e75, но различается длина мантиссы. IEEE754 single до 3.4e38, то есть предел порядка в 2 раза меньше. Зато точность расчётов на IEEE754 сильно выше из-за отсутствия прыжков "следующий порядок => теряем сразу 4 бита точности".
Мои старшие товарищи single не использовали. Да, на ЕС он был порядка 1e64.
N>Ну чем там брала ЕС1036, не знаю, а по сравнению со всякими 1022 и 1033 писюки уже неплохо шли
1022 я помню плохо. 1020 — тормоз. 1036 с СВМ и BOS 7.3 заметно обгоняла 1033 с ОС 6.1.
N>Или эта ваша 286 была без сопроцессора? Тогда, конечно, ад и сектор Газа.
Сопроцессор был. Не помню уже, в чем затык. Может, я не все ключи компилятору правильно расставил. например, забыл задать /i2, и целые числа все были integer*4. На 16-битовом процессоре имело значение. Когда появился 386 и 32-битовый Фортран (ЕМНИП, Fortran Power Station), сразу стало полегче.
Здравствуйте, vsb, Вы писали:
vsb>На мой взгляд технология умирает, когда её перестают применять в новых проектах (в заметном количестве). По этому параметру Cobol умер, Delphi умерло, например. .NET, Java, C++ живей всех живых.
vsb>А если просто смотреть на то, есть ли где-то запущенный код, то и через 100 лет будет кобол где-нибудь работать.
Логичный критерий, и, увы, реально живыми остаются только Python и JavaScript, лишь в едва заметном количестве новых мобильных приложений, ну и в старых, используется Swift, подавляющее большинство новых — на Cordova, редкие старые API бывают на C# и Java, новые почти все на Python.
Здравствуйте, bzig, Вы писали:
B>Соответственно, темы, вроде соседней, просто не имеют смысла. Пока x86 жива и используется, .Net, C++, C, Java и прочие никуда не денутся.
Если x86 умрёт, C, C++ и Java никуда не денутся, т.к. есть для других аппаратных платформ. .NET Core 3.0 есть под ARM.
Здравствуйте, vsb, Вы писали:
vsb>На мой взгляд технология умирает, когда её перестают применять в новых проектах (в заметном количестве). По этому параметру Cobol умер, Delphi умерло, например. .NET, Java, C++ живей всех живых.
Глупость, как всегда от тебя
vsb>А если просто смотреть на то, есть ли где-то запущенный код, то и через 100 лет будет кобол где-нибудь работать.
А поддерживать этот запущенный код кто будет?
Здравствуйте, Тёма, Вы писали:
Тё>Я категорически не согласен с формулировкой. Любому нормальному программисту очевидно, что именно YYY всё, а с XXX ещё сто лет ничего не будет.
Здравствуйте, mrTwister, Вы писали:
T>А я Ленина в мавзолее видел. Умер, ага.
Я Кобол видел не в мавзолее и и не на старых распечатках. Видел я его во вполне реальном проекте. Мне периодически в качестве доки data division присылали, чтобы я знал, как разбирать их ответы на наши запросы. У них тогда был самопальный протокол. Позже они на XML перешли, стало привычнее.
Здравствуйте, vdimas, Вы писали:
P>>На ЕС ЭВМ Ассемблер был довольно популярен.
V>Так там Асемблер довольно-таки высокоуровневый, в отличие от x80/x86 и даже PDP-11/ДВК.
В чём это выражается-то? В паре команд типа EDMK или SRDA? Остальное слабее названных аналогов, как для программиста.
V>Плюс мощная макросистема.
Макры — да. Но и они в основном коде использовались в основном для вызова системных функций.
Остальное — ручками, ручками.
Здравствуйте, netch80, Вы писали:
V>>Так там Асемблер довольно-таки высокоуровневый, в отличие от x80/x86 и даже PDP-11/ДВК. N>В чём это выражается-то?
В возможностях процессора.
N>В паре команд типа EDMK или SRDA?
В паре десятков. ))
Например, можно прибавлять число прямо в адрес памяти (т.е. в обычную символьную переменную) и сразу ветвиться по условию.
В отличие от, организация пары вложенных циклов на асме x86 — та еще боль.
Плюс постоянная необходимость сохранять/восстанавливать регистры на каждый чих.
Можно одной командой сравнить одну строку с другой, без дурацкого вызова подпрограмм и связанного с этим манипуляциями со стеком и регистрами.
Лень копаться в воспоминаниях слишком глубоко, да и ничего из накопанного тебе всё-равно будет не интересно.
N>Остальное слабее названных аналогов, как для программиста.
И зачем опять пытаться демонстрировать беспричинную радикальность? ))
Одни и те же алгоритмы на асме IBM/360 записывались в ~4-5 раз короче, чем на асме x86.
Если же брать куда как более мощную систему команд современного x86_64, то всё равно минимум в два раза "современный" асм тому древнему сольёт.
ИМХО, никаких иных характеристик "мощности", кроме выразительности, у сравнимых по назначению и технологиям языков быть не может.
(если рассматривать "АПИ" процессора как язык, а это он и есть)
V>>Плюс мощная макросистема. N>Макры — да. Но и они в основном коде использовались в основном для вызова системных функций.
Для вызова любых ф-ий.
Для организации часто используемых блоков кода.
Для превращения программы на Ассемблере в практически нормальную программу, бо содержали ветвление от параметров.
Для сравнения, макроподсистема макроассемблеров x86 практически никогда не использовалась, а в IBM/360 было невозможно представить относительно сложную программу без того, чтобы она процентов от 20% или более не состояла из макросов и их вызовов.
Это тоже настолько красноречиво, что пытаться утверждать "да это почти одно и то же" — радикализм.
N>Остальное — ручками, ручками.
Не, ручками это в PDP-11, хотя и он архитектурно vs x86 — вершина мысли.
И всё-равно — только там мог появиться "макроассемблер следующего уровня", то бишь язык Си.
На IBM/360 он бы не появился ни в жисть за ненадобностью.
Здравствуйте, Privalov, Вы писали:
P>Я очень плохо знаком с Ассемблером ЕС ЭВМ. Что в тем такого высокоуровневого?
Может быть отсутствие аппаратного стека
Или адресация по умолчанию к каким-то смешным сегментам по 4 Кб. В командах переходов тоже.
Здравствуйте, pagid, Вы писали:
P>Может быть отсутствие аппаратного стека
Кстати, боль. Там надо было выделить память, сохранить указатель на нее, все руками, не? Потом вовремя освободить.
P>Или адресация по умолчанию к каким-то смешным сегментам по 4 Кб. В командах переходов тоже.
Не сегментам, секциям. ну да, у ЕС была 12-битовая шина адреса. Деталей не помню. Книга Востриковой с тех времен осталась, но толку с нее сейчас, если запустить и проверить негде. А голая теория, тем более, давно забытая, не катит.
Здравствуйте, pagid, Вы писали:
P>>Я очень плохо знаком с Ассемблером ЕС ЭВМ. Что в тем такого высокоуровневого? P>Может быть отсутствие аппаратного стека
А сильно аппаратный стек помогал?
И зачем позже появились команды, навроде enter в x86?
Аппаратура не справлялась?
P>Или адресация по умолчанию к каким-то смешным сегментам по 4 Кб. В командах переходов тоже.
Ты про короткие и длинные переходы?
А разве аналогичных команд нет в x86?
Здравствуйте, vdimas, Вы писали:
V>Например, можно прибавлять число прямо в адрес памяти (т.е. в обычную символьную переменную) и сразу ветвиться по условию.
Ты названия давай, а не описания от балды. А то что-то не находится. Семейства BCT, BXH, BXLE все требуют регистра для переменной цикла. Документация доступна, сейчас перепроверил — нет такого.
Что-то с памятью твоей стало.
V>В отличие от, организация пары вложенных циклов на асме x86 — та еще боль. V>Плюс постоянная необходимость сохранять/восстанавливать регистры на каждый чих.
Везде надо сохранять регистры "на каждый чих", когда их не хватает.
Разве что через LM/STM их скопом удобнее гонять туда-обратно.
N>>В паре команд типа EDMK или SRDA? V>В паре десятков. ))
Список в студию. Пока что твои воспоминания явно страдают.
V>Можно одной командой сравнить одну строку с другой, без дурацкого вызова подпрограмм и связанного с этим манипуляциями со стеком и регистрами.
Появилось только в S/390. ЕС ЭВМ, говоришь? И тут мимо.
V>Лень копаться в воспоминаниях слишком глубоко, да и ничего из накопанного тебе всё-равно будет не интересно.
Почему же, интересно. Как мера беспочвенной фантазии
N>>Остальное слабее названных аналогов, как для программиста. V>И зачем опять пытаться демонстрировать беспричинную радикальность? )) V>Одни и те же алгоритмы на асме IBM/360 записывались в ~4-5 раз короче, чем на асме x86. V>Если же брать куда как более мощную систему команд современного x86_64, то всё равно минимум в два раза "современный" асм тому древнему сольёт.
Фантаст, одна штука.
Посмотри на код, что генерируется для systemz, и удивись.
И я как-то мерял одну и ту же софтину (прокси сетевого протокола) для разных архитектур:
не проходят твои слова.
V>Для превращения программы на Ассемблере в практически нормальную программу, бо содержали ветвление от параметров.
Дададад. Ты точно всё забыл. Всякие AIF могли зависеть только от переменных, известных на этапе компиляции.
V>Для сравнения, макроподсистема макроассемблеров x86 практически никогда не использовалась, а в IBM/360 было невозможно представить относительно сложную программу без того, чтобы она процентов от 20% или более не состояла из макросов и их вызовов.
Исходники доступны. Нет, нету там никаких 20%. А вот макры в качестве системных вызовов — да, сплошь и рядом.
N>>Остальное — ручками, ручками. V>Не, ручками это в PDP-11, хотя и он архитектурно vs x86 — вершина мысли. V>И всё-равно — только там мог появиться "макроассемблер следующего уровня", то бишь язык Си. V>На IBM/360 он бы не появился ни в жисть за ненадобностью.
Возьми исходники и почитай. Сразу поймёшь цену этим воспоминаниям детства
Здравствуйте, Privalov, Вы писали:
P>>Может быть отсутствие аппаратного стека P>Кстати, боль. Там надо было выделить память, сохранить указатель на нее, все руками, не? Потом вовремя освободить.
Ну вообще-то это всё автоматизировалось стандартными прологом-эпилогом.
Код начинался чем-то типа
STM 14,12,0(13)
BALR 15,0
USING *,15
ST 13,сколько-то(15)
LA 13,сколько-то+4(15) -- для области связи вызываемых подпрограмм; можно было пропустить
и заканчивался
L 13,сколько-то(15)
LM 14,12,0(13)
BR 14
ну с поправкой на то, что регистры надо было модифицировать для данных.
Компилятор эти прологи-эпилоги сам генерировал, вестимо.
Современный код, если компилировать C, использует фактически стек:
int foo(int a, int b) {
return a+b;
}
foo:
ldgr %f0,%r15 ; f0 для сохранения указателя, ржачно
lay %r15,-168(%r15) ; вот тут зачем-то аллоцировали дохрена места в стеке
a %r2,%r3
lgdr %r15,%f0
br %r14
но, думаю, для кобола и прочих этого не делают.
P>>Или адресация по умолчанию к каким-то смешным сегментам по 4 Кб. В командах переходов тоже.
Здравствуйте, netch80, Вы писали:
V>>Например, можно прибавлять число прямо в адрес памяти (т.е. в обычную символьную переменную) и сразу ветвиться по условию. N>Ты названия давай, а не описания от балды.
Например AP
N>А то что-то не находится.
плохо ищется
N>Семейства BCT, BXH, BXLE все требуют регистра для переменной цикла.
Но я говорил об арифметике прямо в памяти, т.е. о налдичии инструкций из семейства storage-storage
N>Документация доступна, сейчас перепроверил — нет такого. N>Что-то с памятью твоей стало.
Иди уже заслуженно ешь шляпу. ))
V>>В отличие от, организация пары вложенных циклов на асме x86 — та еще боль. V>>Плюс постоянная необходимость сохранять/восстанавливать регистры на каждый чих. N>Везде надо сохранять регистры "на каждый чих", когда их не хватает.
Их не просто так в x86 не хватало, а по ряду причин:
— отсутствие арифметики класса storage-storage, register-storage;
— обилие уникальных команд для уникальных регистров, что заставляло (а) тусовать данные по регистрам и (б) через память;
— сам файл регистров мал;
— отсутствие логического переименования регистров;
V>>Можно одной командой сравнить одну строку с другой, без дурацкого вызова подпрограмм и связанного с этим манипуляциями со стеком и регистрами. N>Появилось только в S/390. ЕС ЭВМ, говоришь? И тут мимо.
Мне был доступен ЕС-1035, который вроде как клон IBM/370.
V>>Лень копаться в воспоминаниях слишком глубоко, да и ничего из накопанного тебе всё-равно будет не интересно. N>Почему же, интересно. Как мера беспочвенной фантазии
Шляпу доел уже?
Ты же всё-равно не ориентируется в ключевых особенностях того ассемблера, в сравнении с x86, зачем споришь?
Чтобы сравнивать, надо было набить руку на обеих асмах в чём-то посложнее, чем H-W!
N>>>Остальное слабее названных аналогов, как для программиста. V>>И зачем опять пытаться демонстрировать беспричинную радикальность? )) V>>Одни и те же алгоритмы на асме IBM/360 записывались в ~4-5 раз короче, чем на асме x86. V>>Если же брать куда как более мощную систему команд современного x86_64, то всё равно минимум в два раза "современный" асм тому древнему сольёт. N>Фантаст, одна штука.
ЧТД.
Не писал ты ни строчки.
N>И я как-то мерял одну и ту же софтину (прокси сетевого протокола) для разных архитектур:
N>344456 aarch64 N>340376 amd64 N>531552 mips64 N>466088 ppc64 N>355752 rv64 (без compressed) N>408640 s390x N>336776 sparc64 N>не проходят твои слова.
Так что ты там мерил?
Работу компилятора?
И насколько он хорош для применённого тобой языка?
V>>Для превращения программы на Ассемблере в практически нормальную программу, бо содержали ветвление от параметров. N>Дададад. Ты точно всё забыл. Всякие AIF могли зависеть только от переменных, известных на этапе компиляции.
1. Ес-но, как и в шаблонном коде на плюсах.
Покажи мне это в MASM?
2. Параметрами макросов могут быть имена регистров или имена переменных в памяти.
Оба раза
V>>Для сравнения, макроподсистема макроассемблеров x86 практически никогда не использовалась, а в IBM/360 было невозможно представить относительно сложную программу без того, чтобы она процентов от 20% или более не состояла из макросов и их вызовов. N>Исходники доступны. Нет, нету там никаких 20%. А вот макры в качестве системных вызовов — да, сплошь и рядом.
Исходники прикладных программ?
N>>>Остальное — ручками, ручками. V>>Не, ручками это в PDP-11, хотя и он архитектурно vs x86 — вершина мысли. V>>И всё-равно — только там мог появиться "макроассемблер следующего уровня", то бишь язык Си. V>>На IBM/360 он бы не появился ни в жисть за ненадобностью. N>Возьми исходники и почитай. Сразу поймёшь цену этим воспоминаниям детства
Мало ли с каким г-ном ты там работаешь?
Ты его всё-равно не понимаешь нихрена, т.е. ни "зачем так", ни "почему именно так".
Тем более, если оно некоего системного плана, т.е. писано с прицелом на переносимость по весьма большой линейке, особенность чего от тебя все-равно ускользнула.
Здравствуйте, netch80, Вы писали:
P>>Кстати, боль. Там надо было выделить память, сохранить указатель на нее, все руками, не? Потом вовремя освободить. N>Ну вообще-то это всё автоматизировалось стандартными прологом-эпилогом.
А всегда ли это нужно?
Правильный ответ — крайне редко.
N>Код начинался чем-то типа N> STM 14,12,0(13) N> BALR 15,0 N> USING *,15 N> ST 13,сколько-то(15) N> LA 13,сколько-то+4(15) -- для области связи вызываемых подпрограмм; можно было пропустить
Это автогенерённая хрень какая-то или на совсем высоких уровнях кода.
Здравствуйте, vdimas, Вы писали:
V>>>Например, можно прибавлять число прямо в адрес памяти (т.е. в обычную символьную переменную) и сразу ветвиться по условию. N>>Ты названия давай, а не описания от балды. V>Например AP
Что, серьёзно? На многобайтной BCD арифметике — циклы? И после этого ещё кто-то говорит о быстродействии?
Ну ладно, если "делать можно всё, что угодно, если вас не интересует конечный результат" — то я согласен, такое извращение там можно сделать. На конкурсе долбодятлов победа обеспечена, да.
N>>Семейства BCT, BXH, BXLE все требуют регистра для переменной цикла. V>Но я говорил об арифметике прямо в памяти, т.е. о налдичии инструкций из семейства storage-storage
В десятки раз медленнее двоичных. Ну-ну.
V>>>В отличие от, организация пары вложенных циклов на асме x86 — та еще боль. V>>>Плюс постоянная необходимость сохранять/восстанавливать регистры на каждый чих. N>>Везде надо сохранять регистры "на каждый чих", когда их не хватает. V>Их не просто так в x86 не хватало, а по ряду причин: V>- отсутствие арифметики класса storage-storage, register-storage;
Register-storage есть начиная с 8086:
add ax,[bx+100]
add [bx+100],ax
и в отличие от BCD извращений S/360 оно работало сразу с нормальной скоростью.
V>- обилие уникальных команд для уникальных регистров, что заставляло (а) тусовать данные по регистрам и (б) через память; V>- сам файл регистров мал; V>- отсутствие логического переименования регистров;
"Логическое переименование" это что? Если переименование для Tomasulo OoO — то оно в S/360 было только в одной из поздних старших моделей, в S/370 тоже не во всех, и вообще было разработано для лечения проблемы с V>- сам файл регистров мал;
f0, f2, f4, f6, и всё. И на целочисленные оно тогда не распространялось — это позже добавили.
Ну а то, что начиная с PPro оно есть во всех x86, сейчас должно быть достаточно.
V>>>Можно одной командой сравнить одну строку с другой, без дурацкого вызова подпрограмм и связанного с этим манипуляциями со стеком и регистрами. N>>Появилось только в S/390. ЕС ЭВМ, говоришь? И тут мимо. V>Мне был доступен ЕС-1035, который вроде как клон IBM/370.
Ну назови команду для S/370.
V>>>Лень копаться в воспоминаниях слишком глубоко, да и ничего из накопанного тебе всё-равно будет не интересно. N>>Почему же, интересно. Как мера беспочвенной фантазии V>Шляпу доел уже?
Ещё не начинал и не собираюсь. Мне выкусывание гланд через зад соседа неинтересно
V>Ты же всё-равно не ориентируется в ключевых особенностях того ассемблера, в сравнении с x86, зачем споришь?
В ключевых — ориентируюсь. И с каких пор это BCD стала ключевой особенностью?
Да от неё все бежали как чёрт от ладана. Если применяли, то только для аналогов экселя на пару операций.
V>Чтобы сравнивать, надо было набить руку на обеих асмах в чём-то посложнее, чем H-W!
Ну и какую руку ты набил? Замедляющую?
N>>>>Остальное слабее названных аналогов, как для программиста. V>>>И зачем опять пытаться демонстрировать беспричинную радикальность? )) V>>>Одни и те же алгоритмы на асме IBM/360 записывались в ~4-5 раз короче, чем на асме x86. V>>>Если же брать куда как более мощную систему команд современного x86_64, то всё равно минимум в два раза "современный" асм тому древнему сольёт. N>>Фантаст, одна штука. V>ЧТД. V>Не писал ты ни строчки.
Писал. Но BCD жутко не любил
V>Так что ты там мерил? V>Работу компилятора? V>И насколько он хорош для применённого тобой языка?
Для C++? Достаточно хорош. Один из лучших в мире на тот момент.
V>>>Для превращения программы на Ассемблере в практически нормальную программу, бо содержали ветвление от параметров. N>>Дададад. Ты точно всё забыл. Всякие AIF могли зависеть только от переменных, известных на этапе компиляции. V>1. Ес-но, как и в шаблонном коде на плюсах. V>Покажи мне это в MASM?
А мы тут не с MASM сравниваем, а твои сказки про "ветвление от параметров" обсуждаем.
V>2. Параметрами макросов могут быть имена регистров или имена переменных в памяти.
И как это влияет на возможность вычисления ветки?
V>Мало ли с каким г-ном ты там работаешь? V>Ты его всё-равно не понимаешь нихрена, т.е. ни "зачем так", ни "почему именно так". V>Тем более, если оно некоего системного плана, т.е. писано с прицелом на переносимость по весьма большой линейке, особенность чего от тебя все-равно ускользнула.
Продолжай. Будешь как Великий Нехочуха Тормоз, с BCD в памяти наперевес.
Здравствуйте, bzig, Вы писали:
B>Ассемблер, возможно, неплохой пример, но был ли он когда-нибудь популярным? Брэйнфак, например, не используется, но он и популярным не был.
JS: That's an interesting case and leads to another development sin software companies often make: using the wrong-level tools for the job. At WordPerfect, everything, including everything, had to be written in assembler. Company policy. If a programmer needed a little one-off utility, it had to be hand-coded and hand-optimized in assembler. They were the only people on Earth writing all-assembler apps for Windows. Insane. It's like making your ballerinas wear balls and chains and taping their arms to their sides. SMS: What should they have been coding in? JS: In those days? C. Or maybe Pascal. Programmers should only use lower-level tools for those parts of the product where they are adding the most value. For example, if you're writing a game where the 3D effects are your major selling point, you can't use an off-the-shelf 3D engine; you have to roll your own. But if the major selling point of your game is the story, don't waste time getting great 3D graphics—just use a library. But WordPerfect was writing UI code that operates in "user time" and doesn't need to be particularly fast. Hand-coded assembler is insane and adds no value.
Это старое интервью, которого нет на сайте Джоэла, там форматирование поехало.
верно подмечено. C# существует не потому что он такой классный, а потому что NET это на сегодня монолитный каркас для кучи приложений.
Вот вчера захотел blazor добавить в webapp, думал надо нугет ставить, оказалось нет, все в NET31 уже включено.
Но теоретически можно заюзать более "правильный" F# и постепенно люди, особенно новички забудут о том что такое сишарп.
т.е. он может даже останется как асм для совсем базовых вещей. хотя там вроде как (в ядре clr) вообще c++. Так что c# не нужен
Здравствуйте, netch80, Вы писали:
V>>>>Например, можно прибавлять число прямо в адрес памяти (т.е. в обычную символьную переменную) и сразу ветвиться по условию. N>>>Ты названия давай, а не описания от балды. V>>Например AP N>Что, серьёзно? На многобайтной BCD арифметике — циклы?
И?
Ты шляпу-то всё-равно съесть должен...
N>И после этого ещё кто-то говорит о быстродействии?
Да.
N>Ну ладно, если "делать можно всё, что угодно, если вас не интересует конечный результат" — то я согласен, такое извращение там можно сделать. На конкурсе долбодятлов победа обеспечена, да.
Ага, все вокруг дураки, один ты умный. ))
В большинстве задач выгодней зачитывать и оперировать непосредственно десятичными разрядами, т.к. преобразование в промежуточное шестнадцатеричное/двоично число и обратно — это умножение, а потом деление. И вот тут быстродействию, действительно, наступает ж-па.
На конкурсе долбодятлов победа обеспечена, да. (С)
N>>>Семейства BCT, BXH, BXLE все требуют регистра для переменной цикла. V>>Но я говорил об арифметике прямо в памяти, т.е. о налдичии инструкций из семейства storage-storage N>В десятки раз медленнее двоичных. Ну-ну.
Очередное нубство.
Медленнее там инструкции storage-storage в сравнении с инструкциями register-register по понятным причинам.
Но это до фени, бо если используются storage-storage, то происходил бы обмен с оперативкой в любом случае, только еще и содержимое регистров портилось бы.
N>и в отличие от BCD извращений S/360 оно работало сразу с нормальной скоростью.
Оно и сейчас работает с херовой скоростью, если в кеши не загружено по точно такой же понятной причине.
N>Писал. Но BCD жутко не любил
Т.е. на каждый чих занимался преобразованием ввода-вывода через умножение/деление?
Рилли?
Я думаю, что ты банально врёшь, из разряда ниасилил, поэтому не помню.
V>>Так что ты там мерил? V>>Работу компилятора? V>>И насколько он хорош для применённого тобой языка? N>Для C++? Достаточно хорош. Один из лучших в мире на тот момент.
Нет на свете хорошего С++ компилятора для мейнфреймов.
И не было никогда.
А который был — уродский, вставлял кучу ненужного кода в любую высокоуровневую ф-ию.
А вот для фортрана более-менее нормальный был.
V>>1. Ес-но, как и в шаблонном коде на плюсах. V>>Покажи мне это в MASM? N>А мы тут не с MASM сравниваем
Давай любой другой для x86-го на 80-е, бгг.
В общем, с MASM и Ко.
Или мы обсуждаем твоё желание посравнивать разные ассемблеры не обладая эрудицией ни там ни там.
N>а твои сказки про "ветвление от параметров" обсуждаем.
Так какие там проблемы, чего ты сформулировать-то не можешь?
V>>2. Параметрами макросов могут быть имена регистров или имена переменных в памяти. N>И как это влияет на возможность вычисления ветки?
Примерно так же как в обычном коде, когда по указателю передаёшь ту или иную переменную в кач-ве параметра из разных участков кода при вызове одной и той же ф-ии.
=================
ОК, я хорошо понимаю, что именно у тебя вызывает ступор — ты ж не в курсе способов ветвлений/переходов в асме 360/370. ))
Ликбез: ветвление часто идёт не на метку(адрес), а по регистру.
Регистр — тоже параметр.
И безусловного перехода нет — они все условные.
И отдельных признаков больше-меньше нет, есть два флага, которые имеют разную семантику для знаковых и беззнаковых вычислений.
Соотв, всегда есть пачка макросов для всевозможных типов условных и безусловных (в т.ч. индексных) ветвлений/переходов.
Здравствуйте, vdimas, Вы писали:
N>>Что, серьёзно? На многобайтной BCD арифметике — циклы? V>И? V>Ты шляпу-то всё-равно съесть должен...
Ага, героическая победа сил добра над силами разума. Ну считай, что съел. Фантазией больше, фантазией меньше
N>>И после этого ещё кто-то говорит о быстродействии? V>Да.
N>>Ну ладно, если "делать можно всё, что угодно, если вас не интересует конечный результат" — то я согласен, такое извращение там можно сделать. На конкурсе долбодятлов победа обеспечена, да.
V>Ага, все вокруг дураки, один ты умный. ))
V>В большинстве задач выгодней зачитывать и оперировать непосредственно десятичными разрядами,
Давно? И почему это не используют современные процессоры?
V> т.к. преобразование в промежуточное шестнадцатеричное/двоично число и обратно — это умножение, а потом деление. И вот тут быстродействию, действительно, наступает ж-па. V>На конкурсе долбодятлов победа обеспечена, да. (С)
И первое место на нём заслуженно разделили между собой: Intel, AMD, ARM, MIPS, RISC-V, POWER (от той же IBM!)... AMD гордо в первом ряду за отказ от всяких DAA в 64-битке...
SystemZ заняла скромное второе место... ибо не анекдот, а жизнь...
N>>>>Семейства BCT, BXH, BXLE все требуют регистра для переменной цикла. V>>>Но я говорил об арифметике прямо в памяти, т.е. о налдичии инструкций из семейства storage-storage N>>В десятки раз медленнее двоичных. Ну-ну. V>Очередное нубство. V>Медленнее там инструкции storage-storage в сравнении с инструкциями register-register по понятным причинам. V>Но это до фени, бо если используются storage-storage, то происходил бы обмен с оперативкой в любом случае, только еще и содержимое регистров портилось бы.
Верно. А теперь вспомним ещё про цену чтения/записи байтиков по одному (потому что на том железе кэшей нынешнего стиля не водилось)...
N>>и в отличие от BCD извращений S/360 оно работало сразу с нормальной скоростью. V>Оно и сейчас работает с херовой скоростью, если в кеши не загружено по точно такой же понятной причине.
Вотъ-с.
N>>Писал. Но BCD жутко не любил
V>Т.е. на каждый чих занимался преобразованием ввода-вывода через умножение/деление? V>Рилли? V>Я думаю, что ты банально врёшь, из разряда ниасилил, поэтому не помню.
Я с "экономическими" расчётами там не возился.
Фактически, работа была — вслед за компилятором ускорить численную библиотеку. А там десятичка только на I/O, и то сидела в отдельных модулях.
V>А который был — уродский, вставлял кучу ненужного кода в любую высокоуровневую ф-ию. V>А вот для фортрана более-менее нормальный был.
Ну покажи выхлоп того фортрана. Кстати, который ты имеешь в виду — G, H, E, AE?
V>>>1. Ес-но, как и в шаблонном коде на плюсах. V>>>Покажи мне это в MASM? N>>А мы тут не с MASM сравниваем V>Давай любой другой для x86-го на 80-е, бгг. V>В общем, с MASM и Ко. V>Или мы обсуждаем твоё желание посравнивать разные ассемблеры не обладая эрудицией ни там ни там.
Нет, сейчас ты обсуждаешь своё желание увести тему вбок на то, что ты знаешь. Поэтому неинтересно.
N>>а твои сказки про "ветвление от параметров" обсуждаем. V>Так какие там проблемы, чего ты сформулировать-то не можешь?
Читающему — давно понятно.
V>>>2. Параметрами макросов могут быть имена регистров или имена переменных в памяти. N>>И как это влияет на возможность вычисления ветки? V>Примерно так же как в обычном коде, когда по указателю передаёшь ту или иную переменную в кач-ве параметра из разных участков кода при вызове одной и той же ф-ии.
V>================= V>ОК, я хорошо понимаю, что именно у тебя вызывает ступор — ты ж не в курсе способов ветвлений/переходов в асме 360/370. ))
Пальцем в небо.
V>Ликбез: ветвление часто идёт не на метку(адрес), а по регистру. V>Регистр — тоже параметр.
В который ещё надо загрузить адрес.
V>И безусловного перехода нет — они все условные.
Формально — нет. BC типа всегда условный, да, но он такой не единственный.
V>И отдельных признаков больше-меньше нет, есть два флага, которые имеют разную семантику для знаковых и беззнаковых вычислений. V>Соотв, всегда есть пачка макросов для всевозможных типов условных и безусловных (в т.ч. индексных) ветвлений/переходов.
Здравствуйте, netch80, Вы писали:
V>>В большинстве задач выгодней зачитывать и оперировать непосредственно десятичными разрядами, N>Давно?
Не просто давно, а изначально и вплоть до времён, пока умножение/деление не перестали быть относительно дорогими.
И это не какая-то тайна Полишинеля.
Уверен, стоит тебе чуть копнуть про десятичным вычислениям и там с первых же строк будет объяснено — зачем оно.
N>И почему это не используют современные процессоры?
Что-то ты совсем банальности спрашиваешь, сорри.
1. Современные процессоры — это развитие простейших (когда-то) архитектур микро-процессоров, в них изначально было вложенно меньше "вычислительного разнообразия" (сформулируем так).
2. Умножение/деление нынче аппаратные, а не микропрограммные или алгоритмические, даже в ядрах начального уровня сегодня минимум по 2 умножителя на ядро, в "нормальных" до 4-х, итого: "умножитель — не ресурс" (С).
Плюс большая ширина современных внутренних шин — т.е. сейчас нет смысла экономить на ширине данных во время вычислений (хотя еще есть смысл экономить во время хранения).
V>> т.к. преобразование в промежуточное шестнадцатеричное/двоично число и обратно — это умножение, а потом деление. И вот тут быстродействию, действительно, наступает ж-па. N>И первое место на нём заслуженно разделили между собой: Intel, AMD, ARM, MIPS, RISC-V, POWER (от той же IBM!)... AMD гордо в первом ряду за отказ от всяких DAA в 64-битке...
А команда-то характерная. ))
DAA — это коррекция после обычного ADD, бо специальных десятичных инструкций не подвезли.
Да еще над всего одним байтом, т.е. надо ручками рисовать цикл простого сложения двух чисел.
Теперь сравни с возможностями десятичной арифметики IBM 360/370.
N>SystemZ заняла скромное второе место... ибо не анекдот, а жизнь...
И?
Архитектура родом из конца 50-х.
То, что она живёт до сих пор — это лучшая её оценка, говорит о продуманности, что до сих пор имеет смысл использовать накопленное для неё ПО.
Разумеется, оно морально устарело уже к концу 80-х, потому что это был памятник CISC.
Разумеется, новые Sparc/RISC были большим шагом вперёд с одновременным изменением сути работы программиста — на Sparc-ах ручками писать на асме было бы идиотизмом.
Как и на любом RISC.
Но это уже тема для отдельной беседы.
У меня же был опыт на асме IBM/370, затем многолетний весьма плотный на асмах 8048/8051/8080/z80/8086/PIC/AVR.
Вот и представь сравнительные ощущения от асма менфреймов и микропроцессоров/микроконтроллеров. ))
Там нечего сравнивать и близко, сорри.
N>Верно. А теперь вспомним ещё про цену чтения/записи байтиков по одному (потому что на том железе кэшей нынешнего стиля не водилось)...
Разве? ))
Конвейер — это уже разновидность кеша.
Поэтому, даже когда мы рассуждаем о десятичной арифметике для счётчика цикла — а какова в реальной жизни ширина данных (в десятичных разрядах)?
2 байта — это уже тысячи, а внутренняя предвыборка проца всегда берёт следующий байт по-умолчанию, поэтому скорость для однобайтных и двухбайтных упакованных чисел была примерно одинаковой. Когда шире и шире — там были варианты, конечно, но это синтетика всё, т.е. не из реальной жизни.
(в смысле синтетика для десятичной арифметики, бо в здравом уме "широкие" и "глубокие" вычисления было выгодней переводить в промежуточный честный двоичный вид, ес-но)
В общем, даже на самых первых IBM/360 конвейер был что-то из 4-х стадий в длину и еще дублированный в ширину — для условных переходов.
(у нас этот старинный динозавр EC-1022 был в старом корпусе ВУЗ-а)
А вот IBM/370 был уже ковёр-самолёт, рядом с теми же x86-ми:
Конвейеры в каждом цикле производят выборку до 8 команд, расшифровку 16 команд, до 3 операций над адресами, до 3 процессорных операций. Всего в системе одновременно обрабатывается до 50 команд.
Ну и, можно же найти характеристики — на тактовой частоте что-то порядка 4 МГц наша институтская EС-1035 показывала быстродействие сравнимое с новыми (на тот момент) 486DX 25 МГц. А тот уже был тоже конвейерным по самое нибалуй с кешами.
Вот и прикинь разницу масштабов архитектур. ))
V>>А который был — уродский, вставлял кучу ненужного кода в любую высокоуровневую ф-ию. V>>А вот для фортрана более-менее нормальный был. N>Ну покажи выхлоп того фортрана.
И зачем ты это спрашиваешь?
Чтобы я искал эмулятор, устанавливал у себя систему, настраивал MVS, Фортран и всё для чего?
Я тебе сразу скажу, где искать — в прологе и эпилоге ф-ий после компилятора.
У большинства ф-ий, который компилировал Фортран, не было никакого пролога-эпилога, использовалось соглашение о передаче и возврате данных в регистрах.
А которые давал компилятор Паскаля и Си — нехилый пролог и эпилог были абсолютно у всех скомпилированных ф-ий, т.е. не взирая — а нужно ли это конкретной ф-ии, есть из неё вызовы других ф-ий и т.д.
V>>Или мы обсуждаем твоё желание посравнивать разные ассемблеры не обладая эрудицией ни там ни там. N>Нет, сейчас ты обсуждаешь своё желание увести тему вбок на то, что ты знаешь. Поэтому неинтересно.
Я тебе рассказал о том, что макросы того асма были крутые, допускали даже условное ветвление.
Ты уже 3-й пост как-то так странно возражаешь... ))
Фиг с ним, проехали...
Предлагаю поверить на слово — макроассемблеры под 8086 и рядом никогда не валялись с макроассемблером IBM/360.
N>>>а твои сказки про "ветвление от параметров" обсуждаем. V>>Так какие там проблемы, чего ты сформулировать-то не можешь? N>Читающему — давно понятно.
Да понятно, что я с полутыка понял суть твоего возражения и давно проржался.
Хотел добиться от тебя чёткой формулировки позиции, дабы оголить нелепость подобных замечаний.
Ну, блин, не школьники же тут рассуждать о том, чего макро-подсистема принципиально может, а чего нет.
Будем считать, что ты малость поторопился с шашкой наголо...
V>>Ликбез: ветвление часто идёт не на метку(адрес), а по регистру. V>>Регистр — тоже параметр. N>В который ещё надо загрузить адрес.
Во-во.
Исскуство написания программ на ассемблере — оно во многом заключается в том, чтобы избегать лишних манипуляций с данными.
Т.е., никаких "в который ещё надо загрузить адрес"!!! ))
Он там уже должен быть как результат предыдущих вычислений...
Всё должно друг в друга гладко входить и выходить, как у ослика Иа! ))
Т.е., расположение в стеке и регистрах данных после вызова одних подпрограмм должно быть максимально близко к тому, что ожидают другие подпрограммы.
(и это почему меня страшно бесили 8048/8051/8080/8086 — из-за резко ограниченного манёвра в этом плане из-за уникальности ролей регистров, в сравнении с теми же PDP-11 или PIC-ами).
(и это почему языки высокого уровня тогда страшно тормозили — они постоянно перекидывали данные из пустого в порожнее, бо не были достаточно умны для гладкого их совмещения)
А помнишь язык Форт?
Помнишь, что он порой работал быстрее ассемблера и почему?
(на самом деле не быстрее ассемблера от хорошего программиста, но быстрее ассемблера от посредственного)
Вот как раз из-за экономии на перетурбациях данных — программист на Форте вынужден разрабатывать АПИ всех внутренних подсистем таким образом, чтобы промежуточных манипуляций с данными было как можно меньше.
Здравствуйте, vdimas, Вы писали:
V>>>В большинстве задач выгодней зачитывать и оперировать непосредственно десятичными разрядами, N>>Давно?
V>Не просто давно, а изначально и вплоть до времён, пока умножение/деление не перестали быть относительно дорогими. V>И это не какая-то тайна Полишинеля. V>Уверен, стоит тебе чуть копнуть про десятичным вычислениям и там с первых же строк будет объяснено — зачем оно.
Уверен, стоит тебе чуть копнуть и подумать о результатах — поймёшь, когда что выгодно. Экономия на конверсии хороша, когда у тебя всех операций штук ну максимум до 20. После этого лучше таки конвертировать и считать в двоичке. Это как раз то, почему "физические" численные расчёты ни один безумец не делает в десятичной, а десятичной остаётся доля только "экономических", в терминах того времени, расчётов, и то достаточно коротких. А сейчас, когда конверсия подешевела, вместо 20 надо подставить 3-5. Ну с плавучкой сложнее, но printf("%a") не зря придумали
N>>И почему это не используют современные процессоры? V>Что-то ты совсем банальности спрашиваешь, сорри.
Так вопрос-то риторический. Но ты и на него начал отвечать одновременно подробно и неправильно
V>1. Современные процессоры — это развитие простейших (когда-то) архитектур микро-процессоров, в них изначально было вложенно меньше "вычислительного разнообразия" (сформулируем так).
Да пофиг, чего оно там развитие. Если в современном процессоре типа x86 или ARM ещё остались элементы того, то они только в деталях внешнего лоска или в рудиментах, которые анноят, но в основном не мешают.
V>2. Умножение/деление нынче аппаратные, а не микропрограммные или алгоритмические, даже в ядрах начального уровня сегодня минимум по 2 умножителя на ядро, в "нормальных" до 4-х, итого: "умножитель — не ресурс" (С). V>Плюс большая ширина современных внутренних шин — т.е. сейчас нет смысла экономить на ширине данных во время вычислений (хотя еще есть смысл экономить во время хранения).
Да даже в тех моделях, где та шина данных была 8-битной, всё равно двоичка была быстрее.
V>>> т.к. преобразование в промежуточное шестнадцатеричное/двоично число и обратно — это умножение, а потом деление. И вот тут быстродействию, действительно, наступает ж-па. N>>И первое место на нём заслуженно разделили между собой: Intel, AMD, ARM, MIPS, RISC-V, POWER (от той же IBM!)... AMD гордо в первом ряду за отказ от всяких DAA в 64-битке... V>А команда-то характерная. )) V>DAA — это коррекция после обычного ADD, бо специальных десятичных инструкций не подвезли. V>Да еще над всего одним байтом, т.е. надо ручками рисовать цикл простого сложения двух чисел. V>Теперь сравни с возможностями десятичной арифметики IBM 360/370.
Ну не нужно эту команду давать, какая разница?
N>>SystemZ заняла скромное второе место... ибо не анекдот, а жизнь... V>И? V>Архитектура родом из конца 50-х. V>То, что она живёт до сих пор — это лучшая её оценка, говорит о продуманности, что до сих пор имеет смысл использовать накопленное для неё ПО.
Нет там никакой продуманности по современным меркам. Костыль на легаси сидит и кривизной погоняет.
Выжила она только потому, что IBM жилы рвёт, но обеспечивает совместимость 50-летнего старья с новым (за счёт денег клиентов), ещё несколько плюшек типа режима "повторить каждую команду дважды и проверить идентичность результатов", ну и потому что самая эффективная виртуализация (вот этой штуки там таки высочайший уровень — я как-нибудь наберусь сил сделать описание, чем они достигают почти нулевых потерь).
И то — сколько таких машин в мире активно работает, ты считал? У меня нет надёжных данных, но получилось, что где-то 50000, плюс-минус полвагона. Для любой другой не столь поддержанной архитектуры в нынешнем мире такое количество — это значит давно забыто и выброшено на свалку. X86 — больше миллиарда, ARM — думаю, уже на десяток миллиардов наберётся.
V>Разумеется, оно морально устарело уже к концу 80-х, потому что это был памятник CISC.
Где да, а где и нет — например, аналогов команды типа add [ebx+esi*4+10],eax там нет — так что по этому набору команд оно менее CISC, чем x86.
V>Разумеется, новые Sparc/RISC были большим шагом вперёд с одновременным изменением сути работы программиста — на Sparc-ах ручками писать на асме было бы идиотизмом. V>Как и на любом RISC. V>Но это уже тема для отдельной беседы.
Нормально пишется. Да, местами более многословно.
V>У меня же был опыт на асме IBM/370, затем многолетний весьма плотный на асмах 8048/8051/8080/z80/8086/PIC/AVR. V>Вот и представь сравнительные ощущения от асма менфреймов и микропроцессоров/микроконтроллеров. )) V>Там нечего сравнивать и близко, сорри.
У меня на PDP-11, 6502, немного 8086 и Z80. Самые кошмары типа 8051 прошли мимо меня. И таки немного S/360. Но к чему это всё, если современные x86 уже начиная 32-битки заметно другие?
N>>Верно. А теперь вспомним ещё про цену чтения/записи байтиков по одному (потому что на том железе кэшей нынешнего стиля не водилось)...
V>Разве? )) V>Конвейер — это уже разновидность кеша.
Он не распространялся на данные, насколько я в курсе тех дизайнов.
V>2 байта — это уже тысячи, а внутренняя предвыборка проца всегда берёт следующий байт по-умолчанию, поэтому скорость для однобайтных и двухбайтных упакованных чисел была примерно одинаковой. Когда шире и шире — там были варианты, конечно, но это синтетика всё, т.е. не из реальной жизни. V>(в смысле синтетика для десятичной арифметики, бо в здравом уме "широкие" и "глубокие" вычисления было выгодней переводить в промежуточный честный двоичный вид, ес-но)
V>В общем, даже на самых первых IBM/360 конвейер был что-то из 4-х стадий в длину и еще дублированный в ширину — для условных переходов. V>(у нас этот старинный динозавр EC-1022 был в старом корпусе ВУЗ-а)
Не могу найти данные про наличие конвейера в моделях младше ЕС1050. Боюсь, ты что-то путаешь.
V>А вот IBM/370 был уже ковёр-самолёт, рядом с теми же x86-ми: V>
V>Конвейеры в каждом цикле производят выборку до 8 команд, расшифровку 16 команд, до 3 операций над адресами, до 3 процессорных операций. Всего в системе одновременно обрабатывается до 50 команд.
URL?
V>Ну и, можно же найти характеристики — на тактовой частоте что-то порядка 4 МГц наша институтская EС-1035 показывала быстродействие сравнимое с новыми (на тот момент) 486DX 25 МГц. А тот уже был тоже конвейерным по самое нибалуй с кешами. V>Вот и прикинь разницу масштабов архитектур. ))
Подозреваю, что причина была совсем не в архитектуре, а, например, в слабом компиляторе — или, если вы её использовали в 16-битном режиме, одно это могло замедлить арифметику в разы.
V>>>А который был — уродский, вставлял кучу ненужного кода в любую высокоуровневую ф-ию. V>>>А вот для фортрана более-менее нормальный был. N>>Ну покажи выхлоп того фортрана. V>И зачем ты это спрашиваешь? V>Чтобы я искал эмулятор, устанавливал у себя систему, настраивал MVS, Фортран и всё для чего?
Ну ты ж странные ссылки находишь. Наверно, и это где-то описано.
V>Я тебе сразу скажу, где искать — в прологе и эпилоге ф-ий после компилятора. V>У большинства ф-ий, который компилировал Фортран, не было никакого пролога-эпилога, использовалось соглашение о передаче и возврате данных в регистрах.
Это скорее всего был таки Fortran AE, или какой-то из более поздних (типа C).
Потому что G был тупой, а H страшно глючный.
V>Предлагаю поверить на слово — макроассемблеры под 8086 и рядом никогда не валялись с макроассемблером IBM/360.
Меня 8086 и не интересует. Интересует уровень хотя бы раннего GNU AS. Возможно, MACRO-11.
V>Во-во. V>Исскуство написания программ на ассемблере — оно во многом заключается в том, чтобы избегать лишних манипуляций с данными. V>Т.е., никаких "в который ещё надо загрузить адрес"!!! )) V>Он там уже должен быть как результат предыдущих вычислений... V>Всё должно друг в друга гладко входить и выходить, как у ослика Иа! ))
Ну может в 1% случаев и получится
V>А помнишь язык Форт? V>Помнишь, что он порой работал быстрее ассемблера и почему? V>(на самом деле не быстрее ассемблера от хорошего программиста, но быстрее ассемблера от посредственного)
Нет, не помню. Не видел такие реализации.
V>Вот как раз из-за экономии на перетурбациях данных — программист на Форте вынужден разрабатывать АПИ всех внутренних подсистем таким образом, чтобы промежуточных манипуляций с данными было как можно меньше.
Здравствуйте, netch80, Вы писали:
N>Уверен, стоит тебе чуть копнуть и подумать о результатах — поймёшь, когда что выгодно. Экономия на конверсии хороша, когда у тебя всех операций штук ну максимум до 20. После этого лучше таки конвертировать и считать в двоичке. Это как раз то, почему "физические" численные расчёты ни один безумец не делает в десятичной, а десятичной остаётся доля только "экономических", в терминах того времени, расчётов, и то достаточно коротких.
Да не бывает в "бизнесе" длинных вычислений.
Только в науке.
Но для науки был Cray, напомню.
А линейка IBM/360 — это сугубо бизнес...
N>А сейчас, когда конверсия подешевела, вместо 20 надо подставить 3-5. Ну с плавучкой сложнее, но printf("%a") не зря придумали
Зря.
(без иронии)
N>Да пофиг, чего оно там развитие.
Да вот не пофик.
Сумасшедшие чуть ли не ИИ-модули переименований регистров внутри современных x86_x64 процов — это наследие убогой исходной архитектуры.
Т.е., программы пишутся (компиллируются) для одной архитектуры, а исполняются унутре совершенно в другой.
И даже Itanium не взлетел... сугубо из-за пресловутого груза совместимости накопленного ПО...
Т.е., "развитие чего" оказалось определяющим.
N>Если в современном процессоре типа x86 или ARM ещё остались элементы того, то они только в деталях внешнего лоска или в рудиментах, которые анноят, но в основном не мешают.
Исключив кеши памяти и IO (оставив только исполнительные модули) — чуть ли не четверть остального железа на кристалле.
Ничего себе "не мешают".
N>Да даже в тех моделях, где та шина данных была 8-битной, всё равно двоичка была быстрее.
Если рассматривать полный цикл память1 = память2 + память3, то дешевле было сложить два 2-хбайтных упакованных десятичных числа, чем два машинных слова по 4 байта.
Если у тебя есть доступ к живым таким современным системам — сравни.
(хотя, в современных расклады могут быть другие, ес-но, но всё-равно любопытно)
N>Нет там никакой продуманности по современным меркам. Костыль на легаси сидит и кривизной погоняет.
Не скажи.
Современные процы вот только недавно научились полноценным трюкам давнишнего IBM VM.
N>ну и потому что самая эффективная виртуализация (вот этой штуки там таки высочайший уровень — я как-нибудь наберусь сил сделать описание, чем они достигают почти нулевых потерь).
На самом деле только из-за этого.
Настолько всё гладко и управляемо, что в современных системах аналогичное достигается через гигантское по размаху управляющее ПО. ))
N>И то — сколько таких машин в мире активно работает, ты считал? У меня нет надёжных данных, но получилось, что где-то 50000, плюс-минус полвагона. Для любой другой не столь поддержанной архитектуры в нынешнем мире такое количество — это значит давно забыто и выброшено на свалку. X86 — больше миллиарда, ARM — думаю, уже на десяток миллиардов наберётся.
С персоналками сравниваешь? ))
N>Где да, а где и нет — например, аналогов команды типа add [ebx+esi*4+10],eax там нет — так что по этому набору команд оно менее CISC, чем x86.
Режимы адресации и прочая виртуализация не имеют к CISC никакого отношения — это всё аппаратная фигня в любом случае.
Похожие режимы адресации есть в Itanium, Эльбрусе и даже AVR: https://studopedia.ru/3_203763_sposobi-adresatsii-v-mikrokontrollerah-AVR.html
(правда, в AVR в команде можно указать только один индексный регистр, но это не принципиально, сам способ примерно такой же)
CISC в IBM/360, в первую очередь, из-за команд, умеющих работать с данными переменной длины.
А для x86 CISC был технологией реализации, разве что.
Сравни, например, RISC AVR и CISC 8051 — первый имеет более богатый набор команд.
В общем, аббревиатура RISC практически с рождения неправильно обозначала то, что обозначала.
V>>У меня же был опыт на асме IBM/370, затем многолетний весьма плотный на асмах 8048/8051/8080/z80/8086/PIC/AVR. V>>Вот и представь сравнительные ощущения от асма менфреймов и микропроцессоров/микроконтроллеров. )) V>>Там нечего сравнивать и близко, сорри.
N>У меня на PDP-11, 6502, немного 8086 и Z80. Самые кошмары типа 8051 прошли мимо меня.
Тю. После 8048 архитектура 8051 воспринимается как отдых для души. ))
N>И таки немного S/360. Но к чему это всё, если современные x86 уже начиная 32-битки заметно другие?
Но на них не пишут программы на асме — только отдельные микроскопические вставки или подпрограммки, сугубо для дёргания того, что невозможно дёргать из ЯВУ.
V>>Конвейер — это уже разновидность кеша. N>Он не распространялся на данные, насколько я в курсе тех дизайнов.
А как ты собрался исполнять в конвейере арифметику над упакованными десятичными числами без предвыборки?
Это невозможно принципиально.
V>>В общем, даже на самых первых IBM/360 конвейер был что-то из 4-х стадий в длину и еще дублированный в ширину — для условных переходов. V>>(у нас этот старинный динозавр EC-1022 был в старом корпусе ВУЗ-а) N>Не могу найти данные про наличие конвейера в моделях младше ЕС1050. Боюсь, ты что-то путаешь.
Боюсь, что нет.
V>>Ну и, можно же найти характеристики — на тактовой частоте что-то порядка 4 МГц наша институтская EС-1035 показывала быстродействие сравнимое с новыми (на тот момент) 486DX 25 МГц. А тот уже был тоже конвейерным по самое нибалуй с кешами. V>>Вот и прикинь разницу масштабов архитектур. )) N>Подозреваю, что причина была совсем не в архитектуре, а, например, в слабом компиляторе — или, если вы её использовали в 16-битном режиме, одно это могло замедлить арифметику в разы.
Тогда уже был Windows 3.1 с модулем 32-битного режима.
Ну и в любом случае в сети есть характеристики той и другой машинки.
V>>Всё должно друг в друга гладко входить и выходить, как у ослика Иа! )) N>Ну может в 1% случаев и получится
Это если ограничивать применение ассемблера теми самими вставками для основной программы на ЯВУ.
А в настоящей ассемблерной проге такого (гладкого) кода намного более половины, т.е. я опять ловлю тебя на том, что ты особо на асмах не писал.
Например, на асме совершенно не требуется возвращать стек к исходной глубине после вызова подпрограмм, т.к. проектирование последовательностей состояний стека — это часть обычной разработки, а на ЯВУ эта часть проектирования отсутствует принципиально.
Далее.
На асме чуть ли не у каждой процедуры более одной точки входа, а на ЯВУ подобное невозможно, там в похожих сценариях получаются вложенные вызовы.
Далее.
Соглашение о вызовах и возвратах результата работает только для публичного АПИ, т.е. только на библиотечном уровне.
В "приватном" коде системы удобней использовать те регистры в подпрограммах, которые не используются (или которые не перезатрут важные данные) от вызывающего кода.
А приватного кода в любой живой программе более 90%.
И т.д. и т.п.
V>>Вот как раз из-за экономии на перетурбациях данных — программист на Форте вынужден разрабатывать АПИ всех внутренних подсистем таким образом, чтобы промежуточных манипуляций с данными было как можно меньше. N>Это не называется "язык работает быстрее".
Здравствуйте, bzig, Вы писали:
B>Соответственно, темы, вроде соседней, просто не имеют смысла. Пока x86 жива и используется, .Net, C++, C, Java и прочие никуда не денутся.
Здравствуйте, vdimas, Вы писали:
V>На асме чуть ли не у каждой процедуры более одной точки входа, а на ЯВУ подобное невозможно, там в похожих сценариях получаются вложенные вызовы.
ЯВУ-они разные бывают, например:
"каждая процедура (procedure) может иметь несколько точек входа (entry), причем каждый дополнительный вход может иметь свои параметры..." (PL/I 1964 год)
\V>Но для науки был Cray, напомню. V>А линейка IBM/360 — это сугубо бизнес...
Суровый матан на ЕС 1033 и 1036 считали только вперед. Я как-то писал: тетки утверждали, что на 1036 неправильный транслятор Фортрана. Дело было около 10 вечера, я был сменным инженером на том ВЦ, влез, нашел ошибку в их программе.
Через несколько лет я тот проект на PC перетаскивал.
Так что совсем не сугубо. Кстати, именно линейка 360 стала универсальной. До нее ЭВМ делились на экономические и научные, ЕМНИП.
V>Если рассматривать полный цикл память1 = память2 + память3, то дешевле было сложить два 2-хбайтных упакованных десятичных числа, чем два машинных слова по 4 байта.
Нас еще в институте за использование DEC FIXED в программах для матана по рукам били. Как раз потому, что тормоз. Попутно учили работать с DEC FLOAT. Многие думали, что DEC FIXED сразу точный результат дает.
V>На асме чуть ли не у каждой процедуры более одной точки входа, а на ЯВУ подобное невозможно, там в похожих сценариях получаются вложенные вызовы.
Ты ж, по идее, должен быть в курсе, что такое оператор ENTRY в Фортране. И, ЕМНИП, такой же был в PL/1. На всякий: этим оперетором обозначалась дополнительная точка входа в процедуру.
В Фортране еще и RETURN n был, позволявший вернуть управление по метке. Я в своем коде такого никогда не использовал. Потому могу напутать.
Вот замаскировать GOTO под RETURN было нельзя, да.
Здравствуйте, vdimas, Вы писали:
V>Да не бывает в "бизнесе" длинных вычислений. V>Только в науке. V>Но для науки был Cray, напомню. V>А линейка IBM/360 — это сугубо бизнес...
Я не знаю, с чего ты взял такую чушь, но ни оригинальная S/360, ни ЕС ЭВМ не была "сугубо бизнесом", и "науки" на ней было в огромном количестве.
Собственно я увидел этого зверя, когда отец стал водить меня на ЕС-1022 киевского НИИ цен, где кафедра брала машинное время (вот тот, да, днём гонял всякий "бизнес" советского планового образца, но вечером начиналось наше время).
N>>А сейчас, когда конверсия подешевела, вместо 20 надо подставить 3-5. Ну с плавучкой сложнее, но printf("%a") не зря придумали
V>Зря. V>(без иронии)
Ну-тко, объясни Тебе нравится применение 1024-битной арифметики на вводе-выводе?
N>>Да пофиг, чего оно там развитие.
V>Да вот не пофик. V>Сумасшедшие чуть ли не ИИ-модули переименований регистров внутри современных x86_x64 процов — это наследие убогой исходной архитектуры. V>Т.е., программы пишутся (компиллируются) для одной архитектуры, а исполняются унутре совершенно в другой.
На System Z то же самое. И на ней, если ты забыл, первой в мире появилось это самое переименование — из-за инвалидского набора 4 плавучих регистров.
N>>Если в современном процессоре типа x86 или ARM ещё остались элементы того, то они только в деталях внешнего лоска или в рудиментах, которые анноят, но в основном не мешают. V>Исключив кеши памяти и IO (оставив только исполнительные модули) — чуть ли не четверть остального железа на кристалле. V>Ничего себе "не мешают".
А теперь покажи такую же раскладку по старшим ARMам или той же System Z. Наверняка будут схожие цифры.
И не надо пропагандировать мертворожденный EPIC — пока не ускорят память (операцию смены строки) хотя бы в 50 раз, out-of-order будет наше всё.
N>>Да даже в тех моделях, где та шина данных была 8-битной, всё равно двоичка была быстрее. V>Если рассматривать полный цикл память1 = память2 + память3, то дешевле было сложить два 2-хбайтных упакованных десятичных числа, чем два машинных слова по 4 байта.
А не надо так рассматривать, потому что актуальные параметры таки кэшировались в регистрах (не всегда оптимально, но тогда уже начали делать алгоритмы, что это умели).
V>Если у тебя есть доступ к живым таким современным системам — сравни. V>(хотя, в современных расклады могут быть другие, ес-но, но всё-равно любопытно)
К System Z сейчас нету, увы. Найду — поразвлекаюсь.
N>>Нет там никакой продуманности по современным меркам. Костыль на легаси сидит и кривизной погоняет. V>Не скажи. V>Современные процы вот только недавно научились полноценным трюкам давнишнего IBM VM.
Так я явно сказал, что виртуализацию исключаю. А вот всякие тупые ограничения адресации (нет PC-relative доступа, беззнаковое смещение), условий (4 условия из двух бит — маловато — в S/390 поэтому добавили RISC-like группу команд типа сравнения с немедленным переходом), просто неэффективность хранения (все короткие коды заняты древними малополезными командами, и для сильно сложного вообще приходится всякие PFPO изобретать) — вот это в полный рост.
N>>ну и потому что самая эффективная виртуализация (вот этой штуки там таки высочайший уровень — я как-нибудь наберусь сил сделать описание, чем они достигают почти нулевых потерь). V>На самом деле только из-за этого. V>Настолько всё гладко и управляемо, что в современных системах аналогичное достигается через гигантское по размаху управляющее ПО. ))
Ну, только или нет — я не буду сильно спорить — думаю, что пачка других мер тоже помогает:
1. Защита оперативной памяти, вплоть до RAID на RAM (а ECC вообще безоговорочно), всех шин (сравни с Intel, у которого даже если память с ECC, ему плевать. AMD хотя бы не позволяет себе такого.)
2. Повторение команд с проверкой (а нефиг тут всяким бозонам летать).
3. Аппаратные LPAR (это ещё и поверх процессорной виртуализации).
4. Мощная контрольная подсистема MCE.
ну и опять же совместимость — пусть у тебя даже ЕС-1020 ещё работает (потребляя тонну спирта в день) — тебе её заменят и юзера и не заметят перехода. Только плати.
N>>И то — сколько таких машин в мире активно работает, ты считал? У меня нет надёжных данных, но получилось, что где-то 50000, плюс-минус полвагона. Для любой другой не столь поддержанной архитектуры в нынешнем мире такое количество — это значит давно забыто и выброшено на свалку. X86 — больше миллиарда, ARM — думаю, уже на десяток миллиардов наберётся. V>С персоналками сравниваешь? ))
Почему сразу с персоналками? Может, с HPC top500?
N>>Где да, а где и нет — например, аналогов команды типа add [ebx+esi*4+10],eax там нет — так что по этому набору команд оно менее CISC, чем x86. V>Режимы адресации и прочая виртуализация не имеют к CISC никакого отношения — это всё аппаратная фигня в любом случае. V>Похожие режимы адресации есть в Itanium, Эльбрусе и даже AVR: https://studopedia.ru/3_203763_sposobi-adresatsii-v-mikrokontrollerah-AVR.html V>(правда, в AVR в команде можно указать только один индексный регистр, но это не принципиально, сам способ примерно такой же)
V>CISC в IBM/360, в первую очередь, из-за команд, умеющих работать с данными переменной длины. V>А для x86 CISC был технологией реализации, разве что. V>Сравни, например, RISC AVR и CISC 8051 — первый имеет более богатый набор команд.
V>В общем, аббревиатура RISC практически с рождения неправильно обозначала то, что обозначала.
Почему, если reduced или rational отнести к instruction, а не set — то правильно. Только почему-то кривое понимание стало позже чуть ли не преобладающим.
V>Тю. После 8048 архитектура 8051 воспринимается как отдых для души. ))
Обоих не видел даже издалека.
N>>И таки немного S/360. Но к чему это всё, если современные x86 уже начиная 32-битки заметно другие? V>Но на них не пишут программы на асме — только отдельные микроскопические вставки или подпрограммки, сугубо для дёргания того, что невозможно дёргать из ЯВУ.
Ну так и на этой мало пишут.
V>>>Конвейер — это уже разновидность кеша. N>>Он не распространялся на данные, насколько я в курсе тех дизайнов. V>А как ты собрался исполнять в конвейере арифметику над упакованными десятичными числами без предвыборки? V>Это невозможно принципиально.
При чём тут вообще конвейер, если это проблемы исполнения внутри одной команды?
V>>>В общем, даже на самых первых IBM/360 конвейер был что-то из 4-х стадий в длину и еще дублированный в ширину — для условных переходов. V>>>(у нас этот старинный динозавр EC-1022 был в старом корпусе ВУЗ-а) N>>Не могу найти данные про наличие конвейера в моделях младше ЕС1050. Боюсь, ты что-то путаешь. V>Боюсь, что нет.
Не убедил
V>>>Ну и, можно же найти характеристики — на тактовой частоте что-то порядка 4 МГц наша институтская EС-1035 показывала быстродействие сравнимое с новыми (на тот момент) 486DX 25 МГц. А тот уже был тоже конвейерным по самое нибалуй с кешами. V>>>Вот и прикинь разницу масштабов архитектур. )) N>>Подозреваю, что причина была совсем не в архитектуре, а, например, в слабом компиляторе — или, если вы её использовали в 16-битном режиме, одно это могло замедлить арифметику в разы. V>Тогда уже был Windows 3.1 с модулем 32-битного режима. V>Ну и в любом случае в сети есть характеристики той и другой машинки.
Есть. И всё равно непонятно. Может, вы даже сопроцессор не применили, всё эмулировалось.
V>>>Всё должно друг в друга гладко входить и выходить, как у ослика Иа! )) N>>Ну может в 1% случаев и получится V>Это если ограничивать применение ассемблера теми самими вставками для основной программы на ЯВУ. V>А в настоящей ассемблерной проге такого (гладкого) кода намного более половины, т.е. я опять ловлю тебя на том, что ты особо на асмах не писал.
V>Например, на асме совершенно не требуется возвращать стек к исходной глубине после вызова подпрограмм, т.к. проектирование последовательностей состояний стека — это часть обычной разработки, а на ЯВУ эта часть проектирования отсутствует принципиально.
Ну так и на ЯВУ не возвращают. Неоднократно видел в выдаче GCC. Возвращают только на финальном выходе. И сделать такое на ассемблере банально.
В общем пример какой-то сомнительный.
V>Далее. V>На асме чуть ли не у каждой процедуры более одной точки входа, а на ЯВУ подобное невозможно, там в похожих сценариях получаются вложенные вызовы.
На современных — да. На старых было — например, в фортране было ENTRY.
Думаю, скоро смогут начать такое снова делать (хотя надо будет переламывать многое).
Вот этот пример уже поинтереснее. Я тебе сам подскажу ещё один: функции с несколькими возвращаемыми значениями. Пока это мало кто умеет. LLVM, например, не допускает ни в одном соглашении вызова. Go умеет, но у него ассемблятор полностью свой и тупой в куче других вещей (у него, например, передача аргументов и результатов только через стек — так что быстродействие лечится кэшом). Swift умеет, но я не смотрел ещё, не эмулируется ли это на ассемблере через память. А хочется — через регистры, сколько хватит (6-10 элементов).
С дополнительными ENTRY возникает, конечно, пачка сложностей — надо все реализации подпиливать. Но, думаю, это несложно, потому что проблемы симметричны проблемам множественных выходов. Только надо уговорить кого-то крупного в стиле LLVM.
V>Далее. V>Соглашение о вызовах и возвратах результата работает только для публичного АПИ, т.е. только на библиотечном уровне. V>В "приватном" коде системы удобней использовать те регистры в подпрограммах, которые не используются (или которые не перезатрут важные данные) от вызывающего кода. V>А приватного кода в любой живой программе более 90%.
Да, и такое тоже видел и сам делал. И что тут такого особенного?
V>И т.д. и т.п.
Не "итд итп", а пока что все примеры кроме одного ни о чём. Вот над ним таки можно подумать.
Но я не думаю, что его цена настолько велика, чтобы говорить про суперспособности ассемблера.
Реально сейчас умение компилятора потратить 100500 миллионов тактов компиляции на оптимальное распределение регистров, исполнительных блоков и т.п. — полезнее затрат программиста на микровылизывание.
V>>>Вот как раз из-за экономии на перетурбациях данных — программист на Форте вынужден разрабатывать АПИ всех внутренних подсистем таким образом, чтобы промежуточных манипуляций с данными было как можно меньше. N>>Это не называется "язык работает быстрее". V>Быстрее работает готовая программа, ес-но.
Ну я слабо верю в такое "чем хуже, тем лучше". Оно работает, да — но ой иногда. Иначе бы Форт снова вышел за пределы своих суперузких ниш.
Здравствуйте, Privalov, Вы писали:
P>Ты ж, по идее, должен быть в курсе, что такое оператор ENTRY в Фортране. И, ЕМНИП, такой же был в PL/1. На всякий: этим оперетором обозначалась дополнительная точка входа в процедуру.
Угу, было такое. Жаль, что потом победил стиль Вирта и всё это отменили. Но, может, это неизбежная часть развития по спирали.
P>В Фортране еще и RETURN n был, позволявший вернуть управление по метке. Я в своем коде такого никогда не использовал. Потому могу напутать.
Ну это было фактически эквивалентом следующего: процедуре назначается тип результата int, обычный return это int 0, по метке — return 1, return 2 и так далее, а в вызываемом наворачивался блок типа
switch (the_proc()) {
case 1: goto label1;
case 2: goto label2;
...
}
Здравствуйте, Privalov, Вы писали:
P>Суровый матан на ЕС 1033 и 1036 считали только вперед.
Думаю, на чём было, на том вы и считали, особо выбирать тогда не приходилось.
Дали бы вам Эльбрус-2, вы бы офигели от примерно в 100 раз большего быстродействия для матана.
Архитектура IBM/360 — она больше про десятки виртуальных машин на одном процессоре, чем про быстродействие.
P>Нас еще в институте за использование DEC FIXED в программах для матана по рукам били.
Для матана...
А если бы вы деньги считали, то вам били бы за неиспользование...
Причём, намного больнее. ))
Здравствуйте, netch80, Вы писали:
N>Угу, было такое. Жаль, что потом победил стиль Вирта и всё это отменили. Но, может, это неизбежная часть развития по спирали.
Сейчас-то ENTRY не особо нужны. Когда вызов подпрограмм был дорогим, тогда ENTRY был полезен, потому что позволял эти вызовы экономить. Многие, особенно математики, предпочитали вообще писать все в главной программе. А 5000 строк в фортрановской программе на ЕС — это было много.
Здравствуйте, vdimas, Вы писали:
V>Думаю, на чём было, на том вы и считали, особо выбирать тогда не приходилось.
У НИИ тогда был выбор, на каком ВЦ арендовать машинное время. Были, например, М-4030, помимо всего прочего, совместимые с ЕС.
V>Дали бы вам Эльбрус-2, вы бы офигели от примерно в 100 раз большего быстродействия для матана.
Не нам. Я как раз на ВЦ работал, у которого НИИ время арендовал. В тот НИИ я через несколько лет попал. Эльбрусов в нашей глухомани не было.
V>Архитектура IBM/360 — она больше про десятки виртуальных машин на одном процессоре, чем про быстродействие.
Как-то сразу пропустил. Виртуальные машины — это как раз про ЕС-1036. Я на ней свою первую персоналку получил, пусть и виртуальную.
Про десятки виртуальных машин — это ты про СВМ ЕС. Хорошая система была. Под ней можно было запустить вообще все, что угодно: ОС 6.1 MVT, ДОС ЕС. Плюс у нее в комплекте шла БОС 7.3 и ПДО (подсистема диалоговой обработки). Я сразу же туда пакеты перфокарт записал. Перфокарточный ввод там тоже был виртуальным, карты на вход можно было подать откуда угодно. И PRIMUS был не нужен.
А еще там был прекрасный редактор xEdit. VIM-у до него, как до Луны крабом.
Но на реальном железе 1036 точно так же шла та самая ОС 6.1 MVT или SVS, в которой виртуальными машинами и не пахло. СВМ ЕС вышла намного позже ОС ЕС.
V>Для матана... V>А если бы вы деньги считали, то вам били бы за неиспользование...
А если бы у бабушки была борода, это был бы дедушка.
Я сейчас не помню, в каком формате хранились данные, объявленные с помощью PICTURE. Но не в BCD, точно.
V>Причём, намного больнее. ))
Сегодня для работы с деньгами все еще используются Кобол и PICTURE. На IBM/390. На машинах поменьше числа с фиксированной точкой делают не на BCD, а с помощью обычных целых.
Пока x86 жива и используется, .Net, C++, C, Java и прочие никуда не денутся.
Плюс тормоза PL-ппрограммы по сравнению с такой же фортрановской.
), ещё несколько плюшек типа режима "повторить каждую команду дважды и проверить идентичность результатов", ну и потому что самая эффективная виртуализация (вот этой штуки там таки высочайший уровень — я как-нибудь наберусь сил сделать описание, чем они достигают почти нулевых потерь).
