Дык в том-то и дело, что только ассемблер позволяет управлять любыми программно доступными регистрами; традиционным образом компилируемые языки, вроде сей и паскаля -- только регистрами, отображёнными на память, а это далеко не все регистры. (И, кстати говоря, интерпретируемые языки и языки, выполняемые на виртуальных машинах тоже, в принципе, могут это делать через специальные функции, а классические Бейсики на 8-разрядных машинках часто имели такую возможность "из коробки" -- что ещё больше размывает границу, придумывают же всякие микропыхтоны).
Ну а в современном С++ ещё и другая проблема: компилятор оптимизирует настолько агрессивно, что зачастую нарушает порядок выполнения операций, и приходится принимать специальные меры (ставить барьеры и т.п.), чтобы он это не творил. Ассемблер же транслирует команды именно в том порядке, в каком их написал программист.
В общем, считать и С/С++, и ассемблер языками низкого уровня куда менее корректно, чем записывать С/С++ и какой-нибудь Пыхтон в одну категорию языков высокого уровня. Водораздел -- не функциональные возможности (их с помощью библиотечных функций или специальных операторов можно обеспечить), а привязанность или её отсутствие с конкретной архитектуре.
Но времена меняются и сегодня такое определение выглядит для меня устаревшим, самое главное потому, что оно мало содержательно.
Тогда надо терминологию менять, а не переиначивать старое на новый лад -- иначе вообще бред и неразбериха получается. Собственно, это везде нас и окружает -- и как раз из-за того, что с терминологией обращаются слишком вольно и никак её не стандартизируют (а если стандартизируют, то как раз не то, что требовалось: скажем, придумали "кибибайты" с "мебибайтами", хотя килобайты и мегабайты никакой путаницы не вызывали -- в отличие от, например, что считать RISC-процессором и что -- микроядерной ОС; ну и с уровнями языков тоже).
Помимо чистого ассемблера, т.е. языка-"обёртки" над набором команд конкретной архитектуры, были широко распространены макроассемблеры, дающие возможность определять макрокоманды для автоматического формирования часто используемых последовательностей команд и данных. Так что по своим возможностям разные трансляторы ассемблера для одной и той же архитектуры могут отличаться очень сильно -- и очень сильно может различаться и сам язык, ведь мнемоники машинных команд -- это лишь его часть, и ассемблер отнюдь не "= мнемоника над ISA", как Вы утверждаете.
Ну а термины "язык высокого уровня" и "язык низкого уровня" появились очень давно -- вместе с Фортраном и Коболом, и как раз для того, чтобы отличать их от языков ассемблера по единственно принципиальной между ними разнице -- привязке к конкретной системе команд или отсутствию такой привязки.
В плане языка программирования это вполне себе высокоуровневый код, никак не привязанный к системе команд и устанавливающий один битик в переменной PORTC. Что данная переменная -- это имя регистра, отображённого на память, ничего принципиально не меняет. (Ну или макрос, разворачивающийся в обращение к памяти по явно заданному адресу -- это уж как определено.) Он является низкоуровневым в силу решаемой задачи -- дёрганья ноги GPIO, -- а не в силу используемого языка программирования.
А вот если б язык был действительно низкого уровня, то пришлось бы писать машинные команды, необходимые для выполнения того же самого, и набор этих команд зависел бы от архитектуры. Скажем, на PDP-11 это можно выполнить одной командой, а на ARM потребуется три.
Думается, Вы, как и многие другие, смешиваете "уровень" языка программирования и "уровень" задач, которые на нём решают. Дрыганье ногами GPIO -- задача низкоуровневая, но решена она может быть и на языке низкого уровня (ассемблере), и языках высокого уровня. Можно, конечно, сказать, что С -- язык более низкого уровня, чем Пыхтон, и с этим я соглашусь, -- но это не делает С языком низкого уровня, подобным ассемблеру: он не привязан к архитектуре, и написанный на нём код сам по себе переносим между различными архитектурами (а вот ассемблерный приходится переписывать полностью).
Вообще-то, язык низкого уровня -- только ассемблер. Фундаментальная разница между низким и высоким уровнем -- "завязанность" или отсутствие таковой на конкретную архитектуру и систему команд. C/С++ в этом плане ничем от условного Пыхтона не отличается: использующий его программист не имеет дела с машинными командами, регистрами процессора и т.д. и т.п.
Синтаксис у GNUсного асма ужасный, и брать его за основу...
Нет ни малейшего намёка за такие базовые для настоящего ассемблера вещи, как макросредства, условная трансляция, блоки повторений и т.д. Их нет и в as -- поскольку его единственной задачей является переваривать выхлоп gcc, а не использоваться для серьёзной ручной работы.
"Современное объявление данных" -- бессмысленное и ничем не лучше, а, скорей, хуже традиционных директив традиционных ассемблеров (вроде .BYTE или .ASCII). И да, а если я хочу строку в UTF-8? А в UTF-32? А в EBCDIC?
Да, про это не знал. Хотя использовать для этого интелы (точней, интеловскую архитектуру) -- такое себе, из-за её крайней ублюдочности, что влечёт огромный расход энергии на единицу работы. Думается, под такую задачу лучше подошёл бы почти любой (псевдо)РИСК -- ARM, MIPS, RISC-V... Правда, в те годы, наверное, китайцы ничего лучше не нашли (ну или иные причины были, не технического характера).
Ну а как выглядели... Крэй, например -- думаю, слыхали про такой. В первом приближении -- та же видюха, но без узлов, специфичных для графики (т.е. матричный процессор в более-менее чистом виде).
А что не просто много, а, пожалуй, основная масса алгоритмов толком не параллелится, я в курсе.
Дык у VM и MVS (как и у исходной OS/360) банально совершенно разное назначение: VM -- это гипервизор, её обязанность -- запускать под собой гостевые операционные системы, а не с прикладными программами работать. Идущая вместе с ней ПДО (забыл, как её по-буржуйски звать) полноценной системой не является, она нужна, по большому счёту, для обслуживания самой СВМ (хотя понятно, что её можно использовать а-ля МС ДОС -- в качестве ОС для "персонального компьютера" в виде виртуальной машины на мэйнфрейме).
В общем, они не исключают, а дополняют друг друга, причём практически не пересекаясь в области применения.
Обратиться на микроконтроллере к любым ячейкам памяти можно, но, скажем, сделать переключалку потоков без ассемблера уже не получится: для этого нужно манипулировать указателями стеков (их может быть несколько), различными управляющими регистрами процессора и т.д. -- в общем, сущностями, о которых язык высокого уровня понятия не имеет (и не должен иметь). Так что абсолютный контроль без ассемблера оказывается невозможен.
Да, это можно сделать средствами встроенного ассемблера -- но, во-первых, это будет таки ассемблер, а не С/С++, а во-вторых, встроенного ассемблера может и не быть (это в GCC или CLANG он есть, а мало ли что экзотическое может потребоваться использовать).
Ну так это уже гигантская компания, получается, пускай и состоящая из очень большого количества мелких подразделений, выполняющих одни и те же функции.
Не убить. Плат там много, остальные продолжать работать. Ну а программы, которые выполнялись на убитой плате, будут, скорей всего, перезапущены автоматом с контрольной точки.
Группы поколений данных? Да, но, как по мне, оно не шибко удобно, хотя вполне себе работает. Но учитывая, что OS/360, похоже, была вообще первой "настоящей большой ОС" в истории (а современная MVS тянет совместимость с ней), трудно было всё сделать и правильно, и удобно :)
Насчёт коробок согласен. Для условной кафешки нужно готовое решение, но она ничем, с точки зрения учёта, закупок и т.д. и т.п., не отличается от 100500 других кафешек. Ну а любая очень крупная контора имеет свои специфические фишки, которые в коробки просто не заложишь -- а значит, хошь-не хошь, а придётся что-то дописывать, переделывать и т.д. и т.п. Ну а поскольку SAP ориентирован, как понимаю, исключительно на крупный бизнес, то там коробка попросту не нужна: у них не бывает клиентов, где можно просто "скопировать программу с дискеты" и всё будет работать.
Лично у меня из прочтения той статьи сложилось впечатление, что автор не SAP как таковой ругает, а говорит о том, что его выбирать приходилось не из-за отсутствия достойных альтернатив, а из-за того, что он де-факто навязывается западными регуляторами.
У него сдвоенное обозначение, но почему, лично я не в курсе. Но вообще, такое бывало достаточно часто, но обычно с забугорными машинами (скажем, ЕС-1040 и ЕС-1055 имели у Роботрона свои собственные обозначения).
Во-первых, это, скорей, не суперкомпьютеры, а кластеры обычных компьютеров: физически там множество компьютеров, каждый под управлением своей собственной ОС и т.д. и т.п.
А во-вторых, на железе от Интел их не строят никогда -- их строят на железе и Невидии, и именно её ГПУ выполняют всю "суперкомпьютерную" обработку, а кто скармливает им работу, абсолютно неважно.
Но таки да, на мэйнфреймах суперкомпьютеры-числодробилки не строят -- они под другие задачи заточены.
Прикладные программы переписывать не требуется, там, насколько мне известно, 100% переносимость (и какой-нибудь прикладной код из 1965-го будет без изменений работать и сейчас), а вот ядро системы (супервизор, грубо говоря) -- необходимо, ведь именно оно обеспечивает возможность работы на 64 битах, оно должно поддерживать новые возможности управления адресными пространствами и т.д. и т.п.
Дык в том-то и дело, что только ассемблер позволяет управлять любыми программно доступными регистрами; традиционным образом компилируемые языки, вроде сей и паскаля -- только регистрами, отображёнными на память, а это далеко не все регистры. (И, кстати говоря, интерпретируемые языки и языки, выполняемые на виртуальных машинах тоже, в принципе, могут это делать через специальные функции, а классические Бейсики на 8-разрядных машинках часто имели такую возможность "из коробки" -- что ещё больше размывает границу, придумывают же всякие микропыхтоны).
Ну а в современном С++ ещё и другая проблема: компилятор оптимизирует настолько агрессивно, что зачастую нарушает порядок выполнения операций, и приходится принимать специальные меры (ставить барьеры и т.п.), чтобы он это не творил. Ассемблер же транслирует команды именно в том порядке, в каком их написал программист.
В общем, считать и С/С++, и ассемблер языками низкого уровня куда менее корректно, чем записывать С/С++ и какой-нибудь Пыхтон в одну категорию языков высокого уровня. Водораздел -- не функциональные возможности (их с помощью библиотечных функций или специальных операторов можно обеспечить), а привязанность или её отсутствие с конкретной архитектуре.
Тогда надо терминологию менять, а не переиначивать старое на новый лад -- иначе вообще бред и неразбериха получается. Собственно, это везде нас и окружает -- и как раз из-за того, что с терминологией обращаются слишком вольно и никак её не стандартизируют (а если стандартизируют, то как раз не то, что требовалось: скажем, придумали "кибибайты" с "мебибайтами", хотя килобайты и мегабайты никакой путаницы не вызывали -- в отличие от, например, что считать RISC-процессором и что -- микроядерной ОС; ну и с уровнями языков тоже).
Помимо чистого ассемблера, т.е. языка-"обёртки" над набором команд конкретной архитектуры, были широко распространены макроассемблеры, дающие возможность определять макрокоманды для автоматического формирования часто используемых последовательностей команд и данных. Так что по своим возможностям разные трансляторы ассемблера для одной и той же архитектуры могут отличаться очень сильно -- и очень сильно может различаться и сам язык, ведь мнемоники машинных команд -- это лишь его часть, и ассемблер отнюдь не "= мнемоника над ISA", как Вы утверждаете.
Ну а термины "язык высокого уровня" и "язык низкого уровня" появились очень давно -- вместе с Фортраном и Коболом, и как раз для того, чтобы отличать их от языков ассемблера по единственно принципиальной между ними разнице -- привязке к конкретной системе команд или отсутствию такой привязки.
В плане языка программирования это вполне себе высокоуровневый код, никак не привязанный к системе команд и устанавливающий один битик в переменной PORTC. Что данная переменная -- это имя регистра, отображённого на память, ничего принципиально не меняет. (Ну или макрос, разворачивающийся в обращение к памяти по явно заданному адресу -- это уж как определено.) Он является низкоуровневым в силу решаемой задачи -- дёрганья ноги GPIO, -- а не в силу используемого языка программирования.
А вот если б язык был действительно низкого уровня, то пришлось бы писать машинные команды, необходимые для выполнения того же самого, и набор этих команд зависел бы от архитектуры. Скажем, на PDP-11 это можно выполнить одной командой, а на ARM потребуется три.
Думается, Вы, как и многие другие, смешиваете "уровень" языка программирования и "уровень" задач, которые на нём решают. Дрыганье ногами GPIO -- задача низкоуровневая, но решена она может быть и на языке низкого уровня (ассемблере), и языках высокого уровня. Можно, конечно, сказать, что С -- язык более низкого уровня, чем Пыхтон, и с этим я соглашусь, -- но это не делает С языком низкого уровня, подобным ассемблеру: он не привязан к архитектуре, и написанный на нём код сам по себе переносим между различными архитектурами (а вот ассемблерный приходится переписывать полностью).
Там ошибок тонна...
Вообще-то, язык низкого уровня -- только ассемблер. Фундаментальная разница между низким и высоким уровнем -- "завязанность" или отсутствие таковой на конкретную архитектуру и систему команд. C/С++ в этом плане ничем от условного Пыхтона не отличается: использующий его программист не имеет дела с машинными командами, регистрами процессора и т.д. и т.п.
Только хотел написать, что перед изучением C стоило бы изучить русский язык хотя б на твёрдую 4 :)
Синтаксис у GNUсного асма ужасный, и брать его за основу...
Нет ни малейшего намёка за такие базовые для настоящего ассемблера вещи, как макросредства, условная трансляция, блоки повторений и т.д. Их нет и в as -- поскольку его единственной задачей является переваривать выхлоп gcc, а не использоваться для серьёзной ручной работы.
"Современное объявление данных" -- бессмысленное и ничем не лучше, а, скорей, хуже традиционных директив традиционных ассемблеров (вроде .BYTE или .ASCII). И да, а если я хочу строку в UTF-8? А в UTF-32? А в EBCDIC?
Но пафоса да, тонна.
Да, про это не знал. Хотя использовать для этого интелы (точней, интеловскую архитектуру) -- такое себе, из-за её крайней ублюдочности, что влечёт огромный расход энергии на единицу работы. Думается, под такую задачу лучше подошёл бы почти любой (псевдо)РИСК -- ARM, MIPS, RISC-V... Правда, в те годы, наверное, китайцы ничего лучше не нашли (ну или иные причины были, не технического характера).
Ну а как выглядели... Крэй, например -- думаю, слыхали про такой. В первом приближении -- та же видюха, но без узлов, специфичных для графики (т.е. матричный процессор в более-менее чистом виде).
А что не просто много, а, пожалуй, основная масса алгоритмов толком не параллелится, я в курсе.
Дык у VM и MVS (как и у исходной OS/360) банально совершенно разное назначение: VM -- это гипервизор, её обязанность -- запускать под собой гостевые операционные системы, а не с прикладными программами работать. Идущая вместе с ней ПДО (забыл, как её по-буржуйски звать) полноценной системой не является, она нужна, по большому счёту, для обслуживания самой СВМ (хотя понятно, что её можно использовать а-ля МС ДОС -- в качестве ОС для "персонального компьютера" в виде виртуальной машины на мэйнфрейме).
В общем, они не исключают, а дополняют друг друга, причём практически не пересекаясь в области применения.
Обратиться на микроконтроллере к любым ячейкам памяти можно, но, скажем, сделать переключалку потоков без ассемблера уже не получится: для этого нужно манипулировать указателями стеков (их может быть несколько), различными управляющими регистрами процессора и т.д. -- в общем, сущностями, о которых язык высокого уровня понятия не имеет (и не должен иметь). Так что абсолютный контроль без ассемблера оказывается невозможен.
Да, это можно сделать средствами встроенного ассемблера -- но, во-первых, это будет таки ассемблер, а не С/С++, а во-вторых, встроенного ассемблера может и не быть (это в GCC или CLANG он есть, а мало ли что экзотическое может потребоваться использовать).
Ну так это уже гигантская компания, получается, пускай и состоящая из очень большого количества мелких подразделений, выполняющих одни и те же функции.
Не убить. Плат там много, остальные продолжать работать. Ну а программы, которые выполнялись на убитой плате, будут, скорей всего, перезапущены автоматом с контрольной точки.
Группы поколений данных? Да, но, как по мне, оно не шибко удобно, хотя вполне себе работает. Но учитывая, что OS/360, похоже, была вообще первой "настоящей большой ОС" в истории (а современная MVS тянет совместимость с ней), трудно было всё сделать и правильно, и удобно :)
Насчёт коробок согласен. Для условной кафешки нужно готовое решение, но она ничем, с точки зрения учёта, закупок и т.д. и т.п., не отличается от 100500 других кафешек. Ну а любая очень крупная контора имеет свои специфические фишки, которые в коробки просто не заложишь -- а значит, хошь-не хошь, а придётся что-то дописывать, переделывать и т.д. и т.п. Ну а поскольку SAP ориентирован, как понимаю, исключительно на крупный бизнес, то там коробка попросту не нужна: у них не бывает клиентов, где можно просто "скопировать программу с дискеты" и всё будет работать.
Лично у меня из прочтения той статьи сложилось впечатление, что автор не SAP как таковой ругает, а говорит о том, что его выбирать приходилось не из-за отсутствия достойных альтернатив, а из-за того, что он де-факто навязывается западными регуляторами.
У него сдвоенное обозначение, но почему, лично я не в курсе. Но вообще, такое бывало достаточно часто, но обычно с забугорными машинами (скажем, ЕС-1040 и ЕС-1055 имели у Роботрона свои собственные обозначения).
Во-первых, это, скорей, не суперкомпьютеры, а кластеры обычных компьютеров: физически там множество компьютеров, каждый под управлением своей собственной ОС и т.д. и т.п.
А во-вторых, на железе от Интел их не строят никогда -- их строят на железе и Невидии, и именно её ГПУ выполняют всю "суперкомпьютерную" обработку, а кто скармливает им работу, абсолютно неважно.
Но таки да, на мэйнфреймах суперкомпьютеры-числодробилки не строят -- они под другие задачи заточены.
На ЕС не встречал (хотя вполне могло быть), а вот на СМках это было обычное дело. IНЖАЛИД ДЕЖИЦЕ оттуда ж пошло :)
Прикладные программы переписывать не требуется, там, насколько мне известно, 100% переносимость (и какой-нибудь прикладной код из 1965-го будет без изменений работать и сейчас), а вот ядро системы (супервизор, грубо говоря) -- необходимо, ведь именно оно обеспечивает возможность работы на 64 битах, оно должно поддерживать новые возможности управления адресными пространствами и т.д. и т.п.
И, кстати, AMODE -- не 16, а 24, описка-с :)
Возможно, из-за того, что клавиатура ЕС-7927 рассчитана на ДКОИ, но собственно терминал внутри использует ASCII (точней, КОИ-что-то-там).