Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится. Один из лучших «боевых» кодов для обучения программированию на ассемблере… стилю… методам…
Код очень аккуратный и продуманный, да. Другое дело, MS DOS этот использует только реальный режим работы; в нем нет страничной адресации, только сегментная. Соответственно, для обучения асму его можно рекомендовать разве что работникам музеев старого железа, ну или создателям эмуляторов.
Адресация и .586 все только упрощают. Этот код можно будет сделать еще лучше и еще компактнее не меняя не стиля ни методов. И для обучения он в миллион раз лучше, чем широко распространенные туториалы построенные на анализе ассемблерных листингов типового С-шного helloworld-a.
Код очень аккуратный и продуманный, даВряд ли Билли модицифировал этот код. MS DOS изначально назывался en.wikipedia.org/wiki/86-DOS и куплен был простым парнем Билли у Seattle Computer Products за жалкие 85k$ в 1981 году.
А в Seattle Computer Products скорее всего работали грамотные парни
Не очень понятно, в чем смысл изучать давно устаревший и довольно убогий по нынешним меркам ассемблер 16-битного режима. Посмотрите на 32-битный или 64-битный код, с расширениями MMX, с расширенной адресацией, там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.
там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.
Угу, вот только в подавляющем большинстве случаев вам ни одна из этих команд вообще никак не пригодится, и ваша 64-х битная программа все равно на 99% будет состоять из тех же самых команд пересылки, переходов и простой арифметики, что и 16-битные сорок лет назад.
Если вы учите ассемблер х86, то исходники MS DOS посмотреть как минимум будет интересно. Если знаете и используете в работе, то естественно, никаких откровений там не найдете
Сейчас в деле SSE/AVX расширения, MMX даже более бесполезен, чем «сопроцессор» (FPU), который тоже почти не используется, но там есть 80-битная плавающая точка.
И где можно посмотреть на боевой 32-64 битный код на ассемблере из серьезного коммерческого проекта подобного уровня?
серьезного коммерческого проекта подобного уровня?
Хм. Хочу напомнить, что в этой статье идет речь о софтинке размером несколько десятков килобайт, которая была написана молодыми разработчиками с опытом работы год-два.
Вы думаете, что в условиях «640кб хватит всем» у разработчиков этого кода были какие то проблемы с возрастом или опытом? А я думаю они задачи решали быстрее, чем набивали в терминалах того времени тот исходный текст…
у разработчиков этого кода были какие то проблемы с возрастом или опытом
Что вы? Не было, конечно. Ещё у них не было проблем с архитектурой, паттернами, тестами, да вообще ни с чем не было. Прелесть разработки софта в самом начале 1980-х была в том, что ты мог выучить полсотни операторов выбранного тобой языка программирования, сесть, и начать писать. И у тебя будет получаться не особо хуже, чем у опытных разработчиков. И то, что получилось, вполне можно будет даже продать. Если ты был в США, а не в СССР, конечно.
Я не думаю что проблематика такой сущности как FAT (активно просуществовавшей от того момента и до наши дней) была в изучении пол сотен операторов языка, и что эта ее реализация могла быть выполнена кем то без опыта.
Нет, конечно, не только в изучении операторов языка. Ещё надо было головой подумать, впрочем, как и всегда :) Но что у вас вызывает скепсис? FAT тех времён ничуть не сложнее, чем курсовые работы на ИТшных специальностях. Их же как-то пишут без опыта?
Да и кто разрабатывал FAT, это не секрет. Первую редакцию сделал Марк МакДональд, ему было тогда 21 год, потом усовершенствовал Тим Патерсон (тот, кто превращал QDOS в MS DOS), если не ошибаюсь, ему было 22, когда он этим занялся.
Да и кто разрабатывал FAT, это не секрет. Первую редакцию сделал Марк МакДональд, ему было тогда 21 год, потом усовершенствовал Тим Патерсон (тот, кто превращал QDOS в MS DOS), если не ошибаюсь, ему было 22, когда он этим занялся.
Вы помните жесткие диски тех времен? Сколько например в % битых секторов могло присутствовать в норме на абсолютно новом диске?! Сколько могло появится в процессе эксплуатации?! FAT тех времен — на абсолютных дровах работала! Многие поздние ФС таких дров даже в жизни не видели — и проектировались по совсем другим принципам в совсем другом мире…
Отлично помню. Как правило, на новых дисках могло быть несколько битых секторов, но их количество измерялось в штуках, от 0 до максимум десятка, а не в процентах. А ещё прекрасно помню, как в FAT реализован механизм защиты от подобных сбоев. DOS вызывает функцию форматирования сектора из BIOS, та форматирует сектор, и если контроллер накопителя при выполнении операции выдаёт отказ, DOS записывает в соответствующий кластер в FAT байт с кодом, указывающим, что кластер с этим сектором сбойный. И впоследствии при записи файлов этот кластер будет пропускаться.
Сложнейшая логика, да? Байт аж на десять. А то и целых пятнадцать. И проектировалась, наверняка, несколько месяцев.
Сложнейшая логика, да? Байт аж на десять. А то и целых пятнадцать. И проектировалась, наверняка, несколько месяцев.
Вы смотрите отсюда назад во времени. Вам кажется, что какие то вещи чрезвычайно просты, когда о них вы читаете в книжке. Но вот на момент создания, это было на самом деле сложнейшей логикой. А за 10ю байтами могли стоять месяцы проектирования и исследований. И было совсем не очевидно, как себя в реальности ведут эти диски и что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки.
Вы смотрите отсюда назад во времени.
Я не вчера родился. Я моложе Билла Гейтса, но старше MS DOS :) И мне довелось под неё попрограммировать ещё тогда, когда это не было некромантией.
Но вот на момент создания, это было на самом деле сложнейшей логикой
Вы так плохо думаете о программистах 1970-х годов? Напомню, на момент создания MS DOS уже без малого десять лет существовали на порядки более сложные Юниксы, а также IBMовские OS/360 и т.д., многозадачные, с виртуальной памятью, разделением ресурсов.
А за 10ю байтами могли стоять месяцы проектирования и исследований.
Вы знаете, это сейчас, с нынешним диким спросом на ИТ-услуги, мы ухитряемся тривиальный код делать так, что работа на день растягивается на месяцы проектирования и исследований. А в те годы за такое бы у виска покрутили и сослали бы из программистов в лаборанты. Не было ничего подобного. Софт писался «как есть». Самым простым и очевидным способом.
И было совсем не очевидно, как себя в реальности ведут эти диски
Как написали в спецификации, так и ведут. Это была вообще не забота программистов файловой системы.
что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки
Знаете, что делает файловая система FAT в таких случаях? Правильно, ничего. Она ничего не знает о проблемах с диском и валится вместе с ним. Вы точно считаете, что они потратили месяцы проектирования и исследований, чтобы прийти к этому решению? :)
Я старше самого x86 и под досом тоже программировал. И точно считаю, что они потратили месяцы и решения там появились не просто так. И наверняка у них были варианты нормально не работающие. Потому, что подобные вещи никогда не проектируются на бумаге с первого раза.
Ну, вам наверное виднее. Лично я не способен узреть рокет сайенс в плоской табличке с кодами кластеров, при том, что четверть века назад мы, подростки, под влиянием «Думов» вполне успешно писали простенькие 3D-движки за несколько дней, владея только Турбо-Паскалем и школьными знаниями тригонометрии. И большинство из нас даже программистами не стали. Поэтому извините, но гипотеза, что чувак, работающий программистом в Майкрософт, на изобретение структуры FAT потратил более пары вечеров, сдаётся менее достоверной, чем гипотеза, что нас вывели рептилоиды с планеты Нибиру :) Особенно если учесть, что до появления FAT уже существовали и более сложные файловые системы, и более простые. И было с чем сравнивать.
Формат файлов MSWORD наверно вам тоже не кажется rocket science… Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)… А текстовые редакторы опять же имели ограничение памяти для работы в сегмент и менее и искали с воистину черепашьей скоростью.
Странная у вас логика, ей-богу. «Вы не едите жирное мясо? Наверное, вам не нравятся и помидоры?»
Вы же вроде как говорили, что вы взрослый дядька, старше IBM PC. Тогда вы должны помнить (или хотя бы знать), что IBM PC — единственный популярный компьютер с сегментной адресацией памяти, и всё, что было ДО него, имело линейное адресное пространство, и всякие WordPerfect'ы (появившиеся раньше MS Word'а) сегментных ограничений на своих платформах не имели. Кроме того, формат файлов RTF появился аж в 1987-м году, а более знакомый нам бинарный формат — вообще в 1990-е. То есть это вообще другая эпоха.
Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)
Вы же вроде как говорили, что вы взрослый дядька, старше IBM PC. Тогда вы должны помнить (или хотя бы знать), что IBM PC — единственный популярный компьютер с сегментной адресацией памяти, и всё, что было ДО него, имело линейное адресное пространство, и всякие WordPerfect'ы (появившиеся раньше MS Word'а) сегментных ограничений на своих платформах не имели. Кроме того, формат файлов RTF появился аж в 1987-м году, а более знакомый нам бинарный формат — вообще в 1990-е. То есть это вообще другая эпоха.
CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще и свалка состояла из еще более мелких файлов, и MS-DOS это все тупо наследовал.
CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще
Надо ж понимать, что это не свойство CP/M, а свойство тех компьютеров, на которых она работала. Хотя для домашних компьютеров 1970-х это и так был огромный объем памяти. Но компьютеры 1970-х не заканчивались машинками на MOS 6502 и i8080, были ведь и профессиональные архитектуры.
MS-DOS это все тупо наследовал.
Наследовал. Кстати, как и структуры файловой системы CP/M. Там она, правда, была основана на экстентах, но структуры корневого каталога и FCB оттуда перекочевали в FAT. По сути, изначально заменили только таблицу экстентов на таблицу кластеров.
И надо заметить, что вояджер до сих пор летит без синего экрана смерти.
У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы. Тогда люди меньше времени тратили на болтавню в бложиках (за их отсутсвием) и больше на научную раборту. Вы наверное не былвали в технических библиотеках, после которых возникает улыбка от того что сейчас выдают за супер технологии. Ладно с узкой литературой, до которой доходят не многие, но например Кнут, которого знают даже школьники, писал в середине 60х. Не надо думать что раз тогда архитектура ПК была 16 битной, и только все начиналось (для ПК) то и писали код люди без опыта, у них была куча опыта и знаний, которые они получали на более серьезных архитектурах. А ограничения в вычислительных возможностях заставляли отпимизировать все и вся, так что там вполне есть чему поучиться.
У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы.
Я вас немного верну с небес троллинга на землю. То, что я (и другие специалисты) считают современными паттернами разработки, имеют вполне определённые даты появления. Первая публикация была в самом конце 1980-х. TDD — тоже детище 1990-х.
А Дональд Кнут в своих трудах описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.
описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.
Именно по этой причине базы данных занимаю террабайты, а программа рассчитывающая коэффициенты экспоненты по набору точек работает минуты на современном ПК, хотя на 8086 данные убирались в мегабайты, а расчет длился секунды.
Но им это не понадобится.
Последний проект, где я видел обширное применение ассемблера, это openssl.
Причём ассемблер вполне там оправдан. Я сравнивал с ассемблерные реализации SHA256 и AES с сишным кодом в полной оптимизации на clang и gcc. Ассемблер оказался на 15% быстрее.
Но поверьте мне, этот код довольно далеко уехал от кода тридцателетней давности.
Если вы хотите писать быстрый код на ассемблере для x86_64, то надо не учить древний MS-DOS, а изучать архитектуру современных процессоров.
Причём ассемблер вполне там оправдан. Я сравнивал с ассемблерные реализации SHA256 и AES с сишным кодом в полной оптимизации на clang и gcc. Ассемблер оказался на 15% быстрее.
Но поверьте мне, этот код довольно далеко уехал от кода тридцателетней давности.
Если вы хотите писать быстрый код на ассемблере для x86_64, то надо не учить древний MS-DOS, а изучать архитектуру современных процессоров.
Понятно, что x86 в чистом виде практически не актуален. Но ведь с нуля начинать писать под core i7 задачка та еще. Если изучать ARM-ы, то там весьма приличный зоопарк. Тут же возможность быстро усвоить принцип и даже что-то легко попробовать (в том же dosemu). Да просто создание .com файла это гораздо более быстрый путь к чему-нибудь работающему на asm, хотя бы из-за того что не надо сразу же разбираться с заголовками.
Не понимаю какие именно принципы можно изучать. Я сам в детстве на уроке информатики программировал в фаре, ввода бинарные опкоды команд альтом, пока другие изучали ворд. Да, это весело и интересно, но не стоит питать иллюзий, что это даст какие-то навыки, которые можно применить в современном программировании.
А если хочется разминки для ума, то есть много более интересных платформ, например почему бы не программировать z80?
Да и под x86 реальный режим есть много очень крутого и интересного кода для вдохновения: исходники дума и других игр, известные демки особенно 256 компо и т.д.
А если хочется разминки для ума, то есть много более интересных платформ, например почему бы не программировать z80?
Да и под x86 реальный режим есть много очень крутого и интересного кода для вдохновения: исходники дума и других игр, известные демки особенно 256 компо и т.д.
> Не понимаю какие именно принципы можно изучать.
Адресация памяти, устройство стека, загрузка выполняемых модулей, выполнение условных переходов на уровне железа, доступ к оборудованию, обработка прерываний, работа с регистрами, в конце концов чтение дизасемблированного кода. Я думаю например все это можно изучать.
> почему бы не программировать z80?
z80 тоже хороший вариант, но исходников OS под z80 недавно не открывали. Я думаю это надо не противопоставлять, а считать что одно дополняет другое.
Адресация памяти, устройство стека, загрузка выполняемых модулей, выполнение условных переходов на уровне железа, доступ к оборудованию, обработка прерываний, работа с регистрами, в конце концов чтение дизасемблированного кода. Я думаю например все это можно изучать.
> почему бы не программировать z80?
z80 тоже хороший вариант, но исходников OS под z80 недавно не открывали. Я думаю это надо не противопоставлять, а считать что одно дополняет другое.
Если изучать ARM-ы, то там весьма приличный зоопарк.«Зоопарк» там — на уровне аппаратной реализации взаимодействия с оборудованием. На прикладном уровне ничего страшного в arm'ах нету и изучается он проще x86. (Неспроста же наиболее дорогие микроконтроллеры основаны на ARM-ядрах.) Впрочем, для сомневающихся есть ещё более простой MIPS.
А вы сначала изучили arm или x86?
> На прикладном уровне ничего страшного в arm'ах нету
Вы о системе комманд и оптимизациях? Или о чем?
> На прикладном уровне ничего страшного в arm'ах нету
Вы о системе комманд и оптимизациях? Или о чем?
Сначала прослушал дебильный курс по созданию *.com-файлов с помощью tasm.exe. Сначала рассказывали про регистры общего назначения AX, BX, CX, DX, потом про указатели на сегменты данных, кода и стека, потом говорили про регистр флагов, который можно только прочитать, и в который нельзя писать. Потом какую-то муть про разницу между прерываниями BIOS и прерываниями DOS. И никто не объяснял, зачем вообще всё это дерьмо надо, когда 16-битный код используется разве что в старых играх, а агрегатами на производстве управляют микроконтроллеры, у которых всё совсем по-другому.
А потом появилась такая очень популярная доступная «игрушка для мальчиков» — Palm Zire 21. Которая, несмотря на свои 2МБ памяти была мега-популярной, и кто дружил с паяльником, ковырялись в ней как могли. Помню, была даже такая программа, которая показывала время, оставшееся до конца пары всё увеличивающимися цифрами, и последние 10 секунд показывались во весь экран. Я тогда с паяльником ещё не подружился :( а литературы по ассемблеру для arm не было почти нигде (зато Фигурнов продавался в каждом газетном киоске). И некоторые сдавали зачёт по ассемблеру, демонстрируя работу кода на своих пальмозаврах, а остальные только с завистью смотрели.
Ну а сейчас есть ресурсы (этот, и на английском и даже кто-то в песочницу тут пишет), как кодить на ассемблере для Малинки. Что позволит решать очень много интересных задач, и зоопарк пугать не должен.
Изучение ассемблера х86 — зря потраченое время, если конечно ты не собираешься посветить свою жизню системному програмимрованию и написанию загрузчиков и бут-менеджеров.
А я пока понемногу мучаю свою Бананку М2.
А потом появилась такая очень популярная доступная «игрушка для мальчиков» — Palm Zire 21. Которая, несмотря на свои 2МБ памяти была мега-популярной, и кто дружил с паяльником, ковырялись в ней как могли. Помню, была даже такая программа, которая показывала время, оставшееся до конца пары всё увеличивающимися цифрами, и последние 10 секунд показывались во весь экран. Я тогда с паяльником ещё не подружился :( а литературы по ассемблеру для arm не было почти нигде (зато Фигурнов продавался в каждом газетном киоске). И некоторые сдавали зачёт по ассемблеру, демонстрируя работу кода на своих пальмозаврах, а остальные только с завистью смотрели.
Ну а сейчас есть ресурсы (этот, и на английском и даже кто-то в песочницу тут пишет), как кодить на ассемблере для Малинки. Что позволит решать очень много интересных задач, и зоопарк пугать не должен.
Изучение ассемблера х86 — зря потраченое время, если конечно ты не собираешься посветить свою жизню системному програмимрованию и написанию загрузчиков и бут-менеджеров.
А я пока понемногу мучаю свою Бананку М2.
Вы о системе комманд и оптимизациях?О системе команд разумеется.
> А вы сначала изучили arm или x86?
Извините, что влезаю — вот я, например, сначала изучил S/360, PDP-11 и 6502. Уже после этого был x86.
И согласен с выводом — ARM проще. А, кроме того, он ещё и современнее. X86 это совершенно адская смесь решений, в которых смотрят даже не на один шаг вперёд, а на полшага, а потом мечутся в совершенно другую сторону, и легаси, хвосты которого растут ещё из 70-х, а два шанса переделать на нормальные были, цензурно говоря, пропущены.
> Вы о системе комманд и оптимизациях? Или о чем?
Я бы сказал, обо всём.
Извините, что влезаю — вот я, например, сначала изучил S/360, PDP-11 и 6502. Уже после этого был x86.
И согласен с выводом — ARM проще. А, кроме того, он ещё и современнее. X86 это совершенно адская смесь решений, в которых смотрят даже не на один шаг вперёд, а на полшага, а потом мечутся в совершенно другую сторону, и легаси, хвосты которого растут ещё из 70-х, а два шанса переделать на нормальные были, цензурно говоря, пропущены.
> Вы о системе комманд и оптимизациях? Или о чем?
Я бы сказал, обо всём.
Применение ассемблера в любой реализации AES оправдана только тем, что под него существует свой набор инструкций… Очень глупо его не использовать — это же отдельные затраты на куске кремния…
Сравните например несколько реализаций древнего DES — от битности в них только косметическиe изменения.
Опять же я например не вижу, зачем можно было бы писать быстрый код на x86_64. Какие то там буквально единичные приложения типа hashcat — и все…
Сравните например несколько реализаций древнего DES — от битности в них только косметическиe изменения.
Опять же я например не вижу, зачем можно было бы писать быстрый код на x86_64. Какие то там буквально единичные приложения типа hashcat — и все…
Для AES-NI ассемблер не очень-то и нужен, там есть интристики.
Но не у всех алгоритмов есть хардварные реализации. И их можно реализовать на нативном ассемблере быстрее, чем это делают современные оптимизирующие компиляторы. Это сложно, муторно, требует знаний работы железа, но в результате это может дать вполне ощутимый профит.
И конечно же, для такой работы никак не пригодится вдохновление ассемблерным кодом древнего доса.
Но не у всех алгоритмов есть хардварные реализации. И их можно реализовать на нативном ассемблере быстрее, чем это делают современные оптимизирующие компиляторы. Это сложно, муторно, требует знаний работы железа, но в результате это может дать вполне ощутимый профит.
И конечно же, для такой работы никак не пригодится вдохновление ассемблерным кодом древнего доса.
Во времена пентиумов-4 или атлонов тот же mplayer с ассемблерными вставками позволял играть DivX без дрыганья.
А 99% других программ не позволяли — и это массово не прижилось…
Новый ренесанс возможен будет после нескольких долгих лет упора в кремний… Когда маркетологам надо будет хоть что то предложить для понижения потребления-повышения производительности…
Новый ренесанс возможен будет после нескольких долгих лет упора в кремний… Когда маркетологам надо будет хоть что то предложить для понижения потребления-повышения производительности…
Новый ренесанс возможен будет после нескольких долгих лет упора в кремний…
Могу только добавить, что даже у кремния есть ещё запас на много лет по оптимизации. Не за счет уплотнения техпроцесса, а за счет усовершенствования «схемогенераторов» а-ля Verilog, или ручной оптимизации.
Сам код — показать не смогу но проект написаный на АСМ-е вполне себе комерческий и современный — могу
avidis.ua/files/Spotter-manual.pdf
Вот эта штука целиком написана на АСМе. Размер дистра с инсталятором — 1.5Мб (без справки)
avidis.ua/files/Spotter-manual.pdf
Вот эта штука целиком написана на АСМе. Размер дистра с инсталятором — 1.5Мб (без справки)
Изучал в универе асм как раз на 16-битном x86. Когда захотелось пописать что-то под Widnows, я не помню чтобы тратил время на изучение особенностей 32-битного кода — и так с ходу было всё понятно.
Если цель изучения — понять как пишутся программы на любом из ассемблеров, то можно изучать хоть ассемблер процессора 6502 (тут может даже чем проще архитектура, тем лучше). А потом, когда все принципы усвоены — справочник по нужному процессору в руки (сами вы всё равно все тонкости всех инструкций вряд ли запомните), и в бой.
Если цель изучения — понять как пишутся программы на любом из ассемблеров, то можно изучать хоть ассемблер процессора 6502 (тут может даже чем проще архитектура, тем лучше). А потом, когда все принципы усвоены — справочник по нужному процессору в руки (сами вы всё равно все тонкости всех инструкций вряд ли запомните), и в бой.
Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится.
Если говорить о программе MASM (ml.exe), то научиться не получится, потому что современные версии сильно изменили синтаксис. В лучшую сторону.
Исходники интересны в первую очередь как музейный экспонат. Примерно как утекшие исходники AWARD BIOS.
Синтаксис ассемблерного кода x86 задан в instruction manual на x86 — и его нельзя изменить в какую то сторону не изменив этот документ, а этот документ может изменить только разработчик — который не был бы тем кем он является если бы по желанию левой пятки менял его в какие либо стороны.
Что там куда поменяли в современных версиях masm никому не интересно (у меня например 8-я стоит сколько себя помню).
Что там куда поменяли в современных версиях masm никому не интересно (у меня например 8-я стоит сколько себя помню).
Попробуйте посмотреть, какой синтаксис генерят gnu-тулзы для х86 :)
AT&T? ну пусть — а какую задачу решает изобретение другого синтаксиса на тот же самый камень?!
Не как у всех? как кому то там удобно? чтоб не платить кому то за что-то?
— все это было не нужно, даже когда этого не было!
Напомню, что средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно. Это только сейчас стало модно скидывать с себя любые задачи по написанию компиляторов на сторонние конторы.
Не как у всех? как кому то там удобно? чтоб не платить кому то за что-то?
— все это было не нужно, даже когда этого не было!
Напомню, что средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно. Это только сейчас стало модно скидывать с себя любые задачи по написанию компиляторов на сторонние конторы.
AT&T-синтаксис достаточно похож на различных архитектурах — одни и те же символы обозначают регистр, непосредственное (immediate) значение, одинаковые псевдооперации; в итоге проще написать программу (компилятор), генерирующую текст на языке ассемблера под несколько различных архитектур, пригодный для подачи на вход в GNU assembler.
intel синтаксис так же похож на различных архитектурах надо ли говорить, что немалая часть архитектур интелом и придумана и синтаксис в каждой новой так или иначе наследовался — как и названия и назначения регистров, и в x86 есть команды из набора 4004, и расширение регистров из набора 8080. Тот же исходник для 8080 транслируется в x86 автоматически на уровне текста. В нем точно так же есть набор правил о том как записываются immediate и что за чем стоит. В итоге не существует какой либо сложности написать как программу компилятор ЯВУ в этот ассемблер (что было сделано ДО того как at&t придумала зачем то этот) так и компилятор этого (и любого) ассемблера в машинные коды (что вообще было сделано одновременно с появлением X86 в конце 70-х). Последнее — ну очень простая программа (представленная в данных исходниках образца 81 года).
А вот с различными архитектурами — не получится. Потому, что на уровне ассемблера переносимости банально нет и быть не может! Следовательно ничего не мешает ему выглядеть в выводе как интел. Т.е. еще раз — «нафиг не нужен». Мало того замусорен, ибо префиксирует основной элемент текста (регистр), когда все нормальные префиксируют редко используемые элементы текста… Т.е. мало того, что велосипед изобрели — еще и колеса квадратные.
А вот с различными архитектурами — не получится. Потому, что на уровне ассемблера переносимости банально нет и быть не может! Следовательно ничего не мешает ему выглядеть в выводе как интел. Т.е. еще раз — «нафиг не нужен». Мало того замусорен, ибо префиксирует основной элемент текста (регистр), когда все нормальные префиксируют редко используемые элементы текста… Т.е. мало того, что велосипед изобрели — еще и колеса квадратные.
> Не как у всех?
AT&T синтаксис является продолжением синтаксиса ассемблера Unix для PDP-11 и VAX, отсюда и специфика построения (например, знак % как префикс регистра, или приёмник последним). Возник он при переносе Unix на x86, и авторов этого процесса меньше всего волновала совместимость с синтаксисом Intel.
> средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно.
Intel и Microsoft они таки были платными. И википедия подтверждает — «were sold» и т.п., а не просто раздавались. И в общем случае развитие шло от того, что средства разработки от поставщика все были платными, к тому, что платные версии вытеснялись всякими GCC, GAs, binutils и т.д., и тогда производитель становился вынужден делать своими версии бесплатными.
AT&T синтаксис является продолжением синтаксиса ассемблера Unix для PDP-11 и VAX, отсюда и специфика построения (например, знак % как префикс регистра, или приёмник последним). Возник он при переносе Unix на x86, и авторов этого процесса меньше всего волновала совместимость с синтаксисом Intel.
> средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно.
Intel и Microsoft они таки были платными. И википедия подтверждает — «were sold» и т.п., а не просто раздавались. И в общем случае развитие шло от того, что средства разработки от поставщика все были платными, к тому, что платные версии вытеснялись всякими GCC, GAs, binutils и т.д., и тогда производитель становился вынужден делать своими версии бесплатными.
Для того чтоб заявлять, что что то кем то вытеснялось — поищите хотя бы целевую аудиторию, для этих средств вытеснения… (пишущую на линуксах на x86 ассемблере)…
Так вот кроме пары гиков делающих это чисто по приколу и пары каких нибудь разработчиков кодеков, которые скорее всего текстовым перепроцессором получают результаты своей писанины напрямую из интеловских кодов — вы их не найдете. Потому что ни один специалист не будет учить 2-й велосипед идентичный первому на уровне функционала. В то же время существует 10-к огромных community пишущих в intel синтаксисе под win.
Так вот кроме пары гиков делающих это чисто по приколу и пары каких нибудь разработчиков кодеков, которые скорее всего текстовым перепроцессором получают результаты своей писанины напрямую из интеловских кодов — вы их не найдете. Потому что ни один специалист не будет учить 2-й велосипед идентичный первому на уровне функционала. В то же время существует 10-к огромных community пишущих в intel синтаксисе под win.
> Потому что ни один специалист не будет учить 2-й велосипед идентичный первому на уровне функционала. В то же время существует 10-к огромных community пишущих в intel синтаксисе под win.
1. Что вы назвали «вторым велосипедом»? Если AT&T синтаксис, то тем специалистам, с которыми я общался, в основном пофиг. Да, они могут ругаться на отдельные детали реализации, на сам факт двух синтаксисов и т.п., но привыкли к обоим и просто воспринимают это как данность уровня «тут бывает зима и течёт дождь или снег».
И в общем утверждение про «не будет учить...» неверно — например, в 90х подавляющее большинство спецов знало одновременно C и Pascal, а они были в большинстве применений примерно наравне; что задали, то и применяли. Сейчас аналогичное происходит у меня на глазах в районе Perl vs. Python, и ещё нескольких чуть более дальних сопоставлениях. Поэтому — никак не могу поддержать вывод про «ни один специалист». Возможно, это специфика вашего окружения или мира Windows. Первое не знаю совсем, второе — в основном издалека.
2. Моё окружение — чуть менее чем все из Unix мира. Причём есть и такие, что на AT&T плюются, а предпочитают Intel — через nasm, yasm и тому подобные средства. Но для них всех AT&T синтаксис это просто факт legacy или (см. выше) «ну вот принято тут так, живём с этим».
Это и ответ на другое ваше утверждение —
> Для того чтоб заявлять, что что то кем то вытеснялось — поищите хотя бы целевую аудиторию, для этих средств вытеснения…
вы тут подразумевали только те средства, что с AT&T? Ну так даже GNU as сейчас умеет Intel синтаксис, если ему такую опцию задать. Но я никак не имел в виду ограничение именно им, это вы уже непонятно откуда выдумали. Верно, началось это движение именно со стороны Столлмана — GCC, binutils и так далее. Но сейчас ему есть масса альтернатив.
Кстати, ещё один пример ещё одного самодостаточного решения — Go (язык). Посмотрите на его ассемблер. А на нём тоже уже пишут всякие переходники.
> разработчиков кодеков, которые скорее всего текстовым перепроцессором получают результаты своей писанины напрямую из интеловских кодов
Не могу принять подобное утверждение. То, что я вижу, показывает противоположное — именно что пишут напрямую.
Что такое «пара гиков делающих это чисто по приколу» — непонятно. Для меня те, кто пишут, например, ассемблерные модули в GnuTLS, в GMP и тому подобные места — ничуть не гики, а взрослые люди, понимающие ответственность за проект, которым пользуется вся планета.
1. Что вы назвали «вторым велосипедом»? Если AT&T синтаксис, то тем специалистам, с которыми я общался, в основном пофиг. Да, они могут ругаться на отдельные детали реализации, на сам факт двух синтаксисов и т.п., но привыкли к обоим и просто воспринимают это как данность уровня «тут бывает зима и течёт дождь или снег».
И в общем утверждение про «не будет учить...» неверно — например, в 90х подавляющее большинство спецов знало одновременно C и Pascal, а они были в большинстве применений примерно наравне; что задали, то и применяли. Сейчас аналогичное происходит у меня на глазах в районе Perl vs. Python, и ещё нескольких чуть более дальних сопоставлениях. Поэтому — никак не могу поддержать вывод про «ни один специалист». Возможно, это специфика вашего окружения или мира Windows. Первое не знаю совсем, второе — в основном издалека.
2. Моё окружение — чуть менее чем все из Unix мира. Причём есть и такие, что на AT&T плюются, а предпочитают Intel — через nasm, yasm и тому подобные средства. Но для них всех AT&T синтаксис это просто факт legacy или (см. выше) «ну вот принято тут так, живём с этим».
Это и ответ на другое ваше утверждение —
> Для того чтоб заявлять, что что то кем то вытеснялось — поищите хотя бы целевую аудиторию, для этих средств вытеснения…
вы тут подразумевали только те средства, что с AT&T? Ну так даже GNU as сейчас умеет Intel синтаксис, если ему такую опцию задать. Но я никак не имел в виду ограничение именно им, это вы уже непонятно откуда выдумали. Верно, началось это движение именно со стороны Столлмана — GCC, binutils и так далее. Но сейчас ему есть масса альтернатив.
Кстати, ещё один пример ещё одного самодостаточного решения — Go (язык). Посмотрите на его ассемблер. А на нём тоже уже пишут всякие переходники.
> разработчиков кодеков, которые скорее всего текстовым перепроцессором получают результаты своей писанины напрямую из интеловских кодов
Не могу принять подобное утверждение. То, что я вижу, показывает противоположное — именно что пишут напрямую.
Что такое «пара гиков делающих это чисто по приколу» — непонятно. Для меня те, кто пишут, например, ассемблерные модули в GnuTLS, в GMP и тому подобные места — ничуть не гики, а взрослые люди, понимающие ответственность за проект, которым пользуется вся планета.
Вы фундаментально путаете понятие «специалист» и понятие «человек который в курсе как бывает и что то где то видел»… Специалист — это тот кто на этом ПИШЕТ причем ручками (т.е. можно увидеть им написанные результаты и вывести статистику), а не тот кто в курсе «как оно там бывает»… А пишущих в at&t относительно пишущих в intel-е в реальном мире и в бинокль не видать. Опять же зачем в GNU СЕЙЧАС вдруг возник интеловский синтаксис — если по вашему все так хорошо с at&t-шным из тогда? Признали ошибку или что — хотят притянуть реальную аудиторию которой не нужен цирк с чуждым процессору синтаксисом?
> А пишущих в at&t относительно пишущих в intel-е в реальном мире и в бинокль не видать.
«В реальном мире» вообще пишущих на ассемблере не видать, а я таки вижу людей, которые пишут и именно на AT&T.
Какой именно мир для вас реальный — понять сложно. Если мир Windows, то согласен, там таких будет исчезающе мало. Но для меня сам этот мир это какая-то соседняя галактика, наблюдаемая только в телескоп.
> Опять же зачем в GNU СЕЙЧАС вдруг возник интеловский синтаксис — если по вашему все так хорошо с at&t-шным из тогда?
Опять передёргиваете, я ни слова не говорил про «всё хорошо». Я говорил, что проблемы не настолько существенны, чтобы от него отказываться.
> Признали ошибку или что — хотят притянуть реальную аудиторию которой не нужен цирк с чуждым процессору синтаксисом?
Настоятельно прошу не подменять понятия. Процессору любой синтаксис ассемблера чужд, как и сам ассемблер. А так — да, потребность в Intel синтаксисе оказалась заметной просто из-за его использования в соседних подотраслях.
Для других архитектур подобного не происходит (что подчёркивает, что специфика в Intel, а не в чём-то ещё).
«В реальном мире» вообще пишущих на ассемблере не видать, а я таки вижу людей, которые пишут и именно на AT&T.
Какой именно мир для вас реальный — понять сложно. Если мир Windows, то согласен, там таких будет исчезающе мало. Но для меня сам этот мир это какая-то соседняя галактика, наблюдаемая только в телескоп.
> Опять же зачем в GNU СЕЙЧАС вдруг возник интеловский синтаксис — если по вашему все так хорошо с at&t-шным из тогда?
Опять передёргиваете, я ни слова не говорил про «всё хорошо». Я говорил, что проблемы не настолько существенны, чтобы от него отказываться.
> Признали ошибку или что — хотят притянуть реальную аудиторию которой не нужен цирк с чуждым процессору синтаксисом?
Настоятельно прошу не подменять понятия. Процессору любой синтаксис ассемблера чужд, как и сам ассемблер. А так — да, потребность в Intel синтаксисе оказалась заметной просто из-за его использования в соседних подотраслях.
Для других архитектур подобного не происходит (что подчёркивает, что специфика в Intel, а не в чём-то ещё).
«В реальном мире» вообще пишущих на ассемблере не видать, а я таки вижу людей, которые пишут и именно на AT&T.
Вот тут по ходу обсуждения обнаружилось аж целое ОДНО коммерческое решение на ASM под win (хотя их не мало). А где можно на этих ваших «людей пишущих в синтаксисе at&t» посмотреть?
Но для меня сам этот мир это какая-то соседняя галактика, наблюдаемая только в телескоп.
Учитывая, что это 90+% рынка десктоп ос — вы телескоп то правильной стороной разверните — а то поле зрения сужено слишком…
Процессору любой синтаксис ассемблера чужд, как и сам ассемблер
Это не подмена понятий — разработка синтаксиса ассемблерных команд задача не много проще, чем разработка самого процессора. И удачные синтаксисы увы встречаются очень не часто. И возникают они не просто так — за ними стоят огромные наборы очень серьезных правил как лингвистики так и логики и специалисты в этих отраслях. Поэтому и нельзя вот так по желанию левой пятки взять и создать «свой синтаксис с блекджеком и тп...».
> Вот тут по ходу обсуждения обнаружилось аж целое ОДНО коммерческое решение на ASM под win (хотя их не мало).
Оно целиком на ассемблере? Или всё же какие-то ключевые моменты?
> А где можно на этих ваших «людей пишущих в синтаксисе at&t» посмотреть?
Да полно вокруг. Просто обычно в нашем мире это выглядит как библиотека (чаще опенсорсная), в которой некоторый набор критичных по скорости элементов написан на ассемблере (а всё остальное как минимум на C).
Вот быстрый скан по компу показал:
— Qt: криптография (в составе web engine) и немного кода базового объекта, AT&T.
— GRUB: AT&T.
— GMP: AT&T.
— libcrypt: свой макропроцессор вокруг AT&T.
— openssl: свой макропроцессор вокруг AT&T.
— Mesa: свои макросы, транслируемые в оба диалекта.
— ffmpeg: свой язык.
— Порция звуковых и видеокодеков типа openh264: вот тут больше всего nasm — который, заметим, близок к Intel, но не идентичен.
— Firefox XPCom: Intel команды процессора, но с Unix метакомандами (типа .section, .align и т.п.)
— Firefox JS движок: оба синтаксиса, Intel включается только видя MSC.
— NSS (Mozilla аналог openssl и gnutls): AT&T.
— NSPR: AT&T (причём даже для сборки под OS/2!)
— libvpx: Intel
Собственно средства разработки типа GCC, binutils, стандартные связные компоненты вроде glibc, языки типа Erlang, код ОС вроде Linux, FreeBSD пропускаю из этого списка. У них тотально AT&T. Хотя в дотнете, понятно, Intel, а у Go вообще свой язык ассемблера (например, AX означает и EAX, и RAX, для любой разрядности — но приёмник у них в конце, как в AT&T). В портах FreeBSD, которых всего сейчас 34 тысячи, nasm для сборки просят аж 48 портов, про большинство которых никогда не слышал; и аж 1 порт просит fasm.
Так что перевес в сторону AT&T не абсолютный, но заметный.
> Учитывая, что это 90+% рынка десктоп ос — вы телескоп то правильной стороной разверните — а то поле зрения сужено слишком…
(мысленно просматривая список своих работ за последние годы) VoIP свич, прокси и раутер биржевого хаба, средства управления и мониторинга HPC, разная провайдерская автоматизация, управлялки железом… какого молота я на вашем десктопе высерплю и зачем мне что-то разворачивать?
> разработка синтаксиса ассемблерных команд задача не много проще, чем разработка самого процессора.
Простите, я это не могу воспринять иначе как странную шутку. Синтаксис ассемблера, при наличии готовой системы команд — задача студенческого уровня.
Если хотите возразить — приведите хотя бы пару проблем, которые встречались в этой теме и для которых нужно было провести действительно серьёзную исследовательскую работу.
Оно целиком на ассемблере? Или всё же какие-то ключевые моменты?
> А где можно на этих ваших «людей пишущих в синтаксисе at&t» посмотреть?
Да полно вокруг. Просто обычно в нашем мире это выглядит как библиотека (чаще опенсорсная), в которой некоторый набор критичных по скорости элементов написан на ассемблере (а всё остальное как минимум на C).
Вот быстрый скан по компу показал:
— Qt: криптография (в составе web engine) и немного кода базового объекта, AT&T.
— GRUB: AT&T.
— GMP: AT&T.
— libcrypt: свой макропроцессор вокруг AT&T.
— openssl: свой макропроцессор вокруг AT&T.
— Mesa: свои макросы, транслируемые в оба диалекта.
— ffmpeg: свой язык.
— Порция звуковых и видеокодеков типа openh264: вот тут больше всего nasm — который, заметим, близок к Intel, но не идентичен.
— Firefox XPCom: Intel команды процессора, но с Unix метакомандами (типа .section, .align и т.п.)
— Firefox JS движок: оба синтаксиса, Intel включается только видя MSC.
— NSS (Mozilla аналог openssl и gnutls): AT&T.
— NSPR: AT&T (причём даже для сборки под OS/2!)
— libvpx: Intel
Собственно средства разработки типа GCC, binutils, стандартные связные компоненты вроде glibc, языки типа Erlang, код ОС вроде Linux, FreeBSD пропускаю из этого списка. У них тотально AT&T. Хотя в дотнете, понятно, Intel, а у Go вообще свой язык ассемблера (например, AX означает и EAX, и RAX, для любой разрядности — но приёмник у них в конце, как в AT&T). В портах FreeBSD, которых всего сейчас 34 тысячи, nasm для сборки просят аж 48 портов, про большинство которых никогда не слышал; и аж 1 порт просит fasm.
Так что перевес в сторону AT&T не абсолютный, но заметный.
> Учитывая, что это 90+% рынка десктоп ос — вы телескоп то правильной стороной разверните — а то поле зрения сужено слишком…
(мысленно просматривая список своих работ за последние годы) VoIP свич, прокси и раутер биржевого хаба, средства управления и мониторинга HPC, разная провайдерская автоматизация, управлялки железом… какого молота я на вашем десктопе высерплю и зачем мне что-то разворачивать?
> разработка синтаксиса ассемблерных команд задача не много проще, чем разработка самого процессора.
Простите, я это не могу воспринять иначе как странную шутку. Синтаксис ассемблера, при наличии готовой системы команд — задача студенческого уровня.
Если хотите возразить — приведите хотя бы пару проблем, которые встречались в этой теме и для которых нужно было провести действительно серьёзную исследовательскую работу.
Оно целиком на ассемблере? Или всё же какие-то ключевые моменты?
Насколько я могу судить по объему кода и функционалу — оно целиком!
Да полно вокруг. Просто обычно в нашем мире это выглядит как библиотека (чаще опенсорсная), в которой некоторый набор критичных по скорости элементов написан на ассемблере
Про криптографию сразу забудьте. Ну не имеет никакого отношения к программированию на ассемблере то, что вы взяли самую оптимальную реализацию AES на x86 ассемблере, которой лет столько же сколько самому AES (и еще одну параллельную которой чуть меньше — на наборе инструкций AES) и над которой работали по сути единичные личности один раз в жизни — а дальше начали ее транслировать из синтаксиса в синтаксис и таскать из проекта в проект, и перебивать там по мелочи для того, чтоб из closed source сделать ее open source и еще раз, чтоб наоборот, с каждой итерацией этого цирка делая только хуже (потому что там других вариантов нет — эти вещи когда один раз нормально пишутся на ассемблере — каждый такт считают и каждый метод по 3 раза обдумывают — и любые переписи их только портят)…
Опять же GRUB — это я так понимаю речь о куске сектора в 512 байт в 16-ти битном коде которому 100500лет и который не позволяет сдохнуть как классу 16-ти битным компиляторам (но скоро сдохнет ибо uefi же)? ну да — много людей наверно денно и ночно его пишут, учитывая, что там с начала существования grub ничего не менялось…
И останутся у вас таким темпом только кодеки и странные закрытые библиотеки из непонятных дров. И придете вы к двум с половиной гиков. А уж в юзерспейсе в линуксе ассемблера вообще не существует. (в виндах — есть).
Простите, я это не могу воспринять иначе как странную шутку. Синтаксис ассемблера, при наличии готовой системы команд — задача студенческого уровня.
Никогда нельзя поручать студенту работу профессионального лингвиста — иначе получаются такие выкидыши дилетантов, как наборы AVR и microchip инструкций. Язык — это очень сложная штука и в нем очень легко налажать. Это не просто текст — это архитектура и это восприятие. Если мнемосхема логична, а код правильно структурирован, нормально выровнен, и имеет разделение оператор-операнды, выбран правильный шрифт и на дисплее строго определенный объем информации — достаточно буквально одного короткого взгляда на страницу текста, чтоб мгновенно понять, что именно этот код делает. Ни один приближенный к естественному язык программирования не дает такой возможности. Потому что вам надо в каждой строке 100500 раз думать, что там в какой последовательности выполняется. в ассемблере выполняется без вариантов сверху вниз. Кроме того система должна быть спроектирована на будущее — т.е. необходимо не просто выстроить логичную схему мнемоник, но и понимать как в эту схему могут добавляться мнемоники которых сейчас еще нет но они будут. Была поучительная история, как раз с интелом в виде скачка с тупиковых мнемоник 8080 (по критерию меньше текста лучше и инклюзивные операторы-операнды) к продуманным и расширяемым Z80 Фейджина (лучше больше зато логично и последовательно, операторы и операнды разделены в столбцах), в интеле просто не дураки сидели и смогли понять где именно они налажали и почему 8080 довольно хреново продавался и код к нему писался не очень. Тогда они отказались от текстовой совместимости в пользу транслятора и все придумали заново! Потому, что если бы в интеле ТОГДА в конце 70-х этого бы не поняли своей ошибки — сейчас бы скорее всего мы жили в другом мире, с совершенно другой архитектурой ПК на вашем столе. Вот вам один пример той самой серьезной исследовательской работы — которая по сути изменила мир через 30 лет.
> Про криптографию сразу забудьте.
> Опять же GRUB
Простите, а чего вы вообще хотели, прося примеры на ассемблере? Чтобы толстый объёмный проект был целиком на нём написан, развивался и поддерживался во всех деталях? Ну так времена, когда так делали, закончились лет 30 назад. Конечно, есть отдельные случаи (раз, два и т.п.), но они погоды не делают. Все стараются сделать небольшое количество переходников там, где без них не обойтись, или вылизывать таки особо критичные места.
> И придете вы к двум с половиной гиков.
А мы и так к ним давно пришли. Всё остальное, кроме тех же особых мест, пишется на уровне не меньше чем переносимый ассемблер по имени «C».
Ибо незачем делать иначе.
> и почему 8080 довольно хреново продавался и код к нему писался не очень
«Товарищ, фантастика на втором этаже» ©
8080 потерял преимущество в пользу Z80 по причинам:
Это говорят все, кто их сравнивал. Я не могу в этом лично участвовать, у меня в то время в working set были PDP-11 советского исполнения и 6502 на «Агате». Но знакомых, которые сами паяли всякие синклеры, Радио-86 и т.п. — около десятка, и их мнение тут единодушно. Как именно писалась какая-нибудь SPHL или MOV SP,HL — для них имело десятое и двадцатое значение.
В общем, не годится пример :) Ещё есть?
> как наборы AVR и microchip инструкций
А что вам не так в синтаксисе AVR? ;)
> Опять же GRUB
Простите, а чего вы вообще хотели, прося примеры на ассемблере? Чтобы толстый объёмный проект был целиком на нём написан, развивался и поддерживался во всех деталях? Ну так времена, когда так делали, закончились лет 30 назад. Конечно, есть отдельные случаи (раз, два и т.п.), но они погоды не делают. Все стараются сделать небольшое количество переходников там, где без них не обойтись, или вылизывать таки особо критичные места.
> И придете вы к двум с половиной гиков.
А мы и так к ним давно пришли. Всё остальное, кроме тех же особых мест, пишется на уровне не меньше чем переносимый ассемблер по имени «C».
Ибо незачем делать иначе.
> и почему 8080 довольно хреново продавался и код к нему писался не очень
«Товарищ, фантастика на втором этаже» ©
8080 потерял преимущество в пользу Z80 по причинам:
- Одно напряжение питания +5 (вместо трёх).
- Реально полезные новые команды (а не просто мнемоники), больше регистров.
Это говорят все, кто их сравнивал. Я не могу в этом лично участвовать, у меня в то время в working set были PDP-11 советского исполнения и 6502 на «Агате». Но знакомых, которые сами паяли всякие синклеры, Радио-86 и т.п. — около десятка, и их мнение тут единодушно. Как именно писалась какая-нибудь SPHL или MOV SP,HL — для них имело десятое и двадцатое значение.
В общем, не годится пример :) Ещё есть?
> как наборы AVR и microchip инструкций
А что вам не так в синтаксисе AVR? ;)
Простите, а чего вы вообще хотели, прося примеры на ассемблере?
Людей я хотел. Который пишут сейчас. А не куски кода написанные в 90-х типа AESа и 16-ти битного загрузчика который туда сюда таскают по проектам, размахивая им как флагом.
SPHL или MOV SP,HL — для них имело десятое и двадцатое значение.
Потому, что они просто слаще меда ничего не едали. И кроме SPHL ничего в жизни не писали. И им тогда совсем не очевидно было, что в будущем регистровых пар которые можно будет положить в SP, будет несколько больше, чем одна, и что записи MOV SP,HL эволюционировавшей в MOV RSP,RSI (x86-64) скоро стукнет 40 лет и даст бог — мы еще в раю будем так писать, а их SPHL через 5 лет просто сдохнет.
А что вам не так в синтаксисе AVR? ;)
Да это же классический идиотизм вида «1 действие — 100500 мнемоник» — та же SPHL вид сбоку, причем во времена когда был доступен анализ чужого опыта в огромном объеме — короче в очередной раз задачу лингвиста решают какие то студенты.
> Людей я хотел. Который пишут сейчас.
Они есть. Знаю лично. Но их один на сто тысяч. И больше и не нужно.
> и что записи MOV SP,HL эволюционировавшей в MOV RSP,RSI (x86-64) скоро стукнет 40 лет и даст бог — мы еще в раю будем так писать, а их SPHL через 5 лет просто сдохнет.
Ничто не мешает вести несколько параллельных мнемоник, если старая перестала удовлетворять. Это не проблема типа «int a» против «var a: int», которая действительно заслуживает внимания и порождает современные ситуации типа Most vexing parse.
Кстати, в регистрах вы ошиблись — HL это BX, а не SI.
> короче в очередной раз задачу лингвиста решают какие то студенты.
Если речь про SPHL — они всё правильно сделали. Когда таких команд было только две — такая мнемоника была выгоднее. Ну и снова — синонимами решается банально.
Если в AVR что-то не понравится, можно выкрутиться так же, хотя по-моему там этой проблемы совсем минимум.
Они есть. Знаю лично. Но их один на сто тысяч. И больше и не нужно.
> и что записи MOV SP,HL эволюционировавшей в MOV RSP,RSI (x86-64) скоро стукнет 40 лет и даст бог — мы еще в раю будем так писать, а их SPHL через 5 лет просто сдохнет.
Ничто не мешает вести несколько параллельных мнемоник, если старая перестала удовлетворять. Это не проблема типа «int a» против «var a: int», которая действительно заслуживает внимания и порождает современные ситуации типа Most vexing parse.
Кстати, в регистрах вы ошиблись — HL это BX, а не SI.
> короче в очередной раз задачу лингвиста решают какие то студенты.
Если речь про SPHL — они всё правильно сделали. Когда таких команд было только две — такая мнемоника была выгоднее. Ну и снова — синонимами решается банально.
Если в AVR что-то не понравится, можно выкрутиться так же, хотя по-моему там этой проблемы совсем минимум.
Ничто не мешает вести несколько параллельных мнемоник
Ну черт возьми зачем в реале нужен этот фирменный линуксовый велосипед? (равно как опен офис-гимп-и вот это все).
короче суть я понял — вы знаете целого одного человека который пишет в этом синтаксисе и целых штук 5 оригинальных проектов если исключить туда сюда таскуемую криптуху и столетний загрузчик — несомненно изобретение нового синтаксиса — того стоило!
Кстати, в регистрах вы ошиблись — HL это BX, а не SI.Конечно — я уже и не помню даже правил транслятора 8080>8086 мне почему то казалось он SI использует в этом случае — да и пофигу — все это мертво.
Когда таких команд было только две — такая мнемоника была выгоднее.
какие в AVR две!?
там сразу с десяток.
Ааа Brown Interrupt List! Закапайте обратно :)
Вот тут пытаются из «этого всего вот» собрать рабочую систему
virtuallyfun.com/wordpress/2018/09/29/ms-dos-v1-25-and-v2-0-source-code-now-on-github/#comments
virtuallyfun.com/wordpress/2018/09/29/ms-dos-v1-25-and-v2-0-source-code-now-on-github/#comments
Код явно не полный. По крайней мере в 1.25 не хватает очень большого количества файлов.
На c#? ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft выпустил код MS-DOS 1.25 и 2.0 под лицензией MIT