Microsoft выпустил код MS-DOS 1.25 и 2.0 под лицензией MIT

https://sourceforge.net/p/freedos/news/2018/09/microsoft-open-sources-old-ms-dos/
  • Перевод
Microsoft выпустил код MS-DOS 1.25 и 2.0 под лицензией MIT, см. соответствующий репозиторий на GitHub, на фразу «for reference purposes» внимание не обращайте, она устарела. Это тот самый код, который ещё в марте 2014 года стал доступен как shared source («смотри, но не трогай») на сайте Музея компьютерной истории (новость на Хабре). Всё, что изменилось теперь — лицензия, и она совместима с GPL.

Обе версии MS-DOS — очень старые, в них не поддержано многое из того, что заработало в последующих. Так, например, лишь во второй из них появились папки и перенаправление при помощи знака "|". Так что, несмотря на совместимость лицензий, вряд ли хотя бы строчка этого кода попадёт в FreeDOS или DOSBOX. Но делу улучшения совместимости анализ их исходников не помешает.

P.S. Там приложены и некоторые исполняемые файлы. Понятно, что BASIC и BASICA в DOSBOX не заработают, им нужен Бейсик в ПЗУ. А MODE заработал, но он «знает» только параметры 40 и 80, а параметры co40, co80 и mono ему неведомы. Ещё заработал MASM, но он для тех, кто в него умеет.

P.P.S. Извиняюсь, что поздновато заметил новость, лучше поздно, чем никогда.
Поделиться публикацией

Похожие публикации

Комментарии 70

    +5
    Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится. Один из лучших «боевых» кодов для обучения программированию на ассемблере… стилю… методам…
      +2
      Код очень аккуратный и продуманный, да. Другое дело, MS DOS этот использует только реальный режим работы; в нем нет страничной адресации, только сегментная. Соответственно, для обучения асму его можно рекомендовать разве что работникам музеев старого железа, ну или создателям эмуляторов.
        +4
        Адресация и .586 все только упрощают. Этот код можно будет сделать еще лучше и еще компактнее не меняя не стиля ни методов. И для обучения он в миллион раз лучше, чем широко распространенные туториалы построенные на анализе ассемблерных листингов типового С-шного helloworld-a.
          0
          Код очень аккуратный и продуманный, да
          Вряд ли Билли модицифировал этот код. MS DOS изначально назывался en.wikipedia.org/wiki/86-DOS и куплен был простым парнем Билли у Seattle Computer Products за жалкие 85k$ в 1981 году.
          А в Seattle Computer Products скорее всего работали грамотные парни
          0
          Не очень понятно, в чем смысл изучать давно устаревший и довольно убогий по нынешним меркам ассемблер 16-битного режима. Посмотрите на 32-битный или 64-битный код, с расширениями MMX, с расширенной адресацией, там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.
          • НЛО прилетело и опубликовало эту надпись здесь
              +3
              там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.

              Угу, вот только в подавляющем большинстве случаев вам ни одна из этих команд вообще никак не пригодится, и ваша 64-х битная программа все равно на 99% будет состоять из тех же самых команд пересылки, переходов и простой арифметики, что и 16-битные сорок лет назад.
              Если вы учите ассемблер х86, то исходники MS DOS посмотреть как минимум будет интересно. Если знаете и используете в работе, то естественно, никаких откровений там не найдете
                +2
                Сейчас в деле SSE/AVX расширения, MMX даже более бесполезен, чем «сопроцессор» (FPU), который тоже почти не используется, но там есть 80-битная плавающая точка.
                  +1
                  И где можно посмотреть на боевой 32-64 битный код на ассемблере из серьезного коммерческого проекта подобного уровня?
                    –2
                    серьезного коммерческого проекта подобного уровня?

                    Хм. Хочу напомнить, что в этой статье идет речь о софтинке размером несколько десятков килобайт, которая была написана молодыми разработчиками с опытом работы год-два.
                      +2
                      Вы думаете, что в условиях «640кб хватит всем» у разработчиков этого кода были какие то проблемы с возрастом или опытом? А я думаю они задачи решали быстрее, чем набивали в терминалах того времени тот исходный текст…
                        0
                        у разработчиков этого кода были какие то проблемы с возрастом или опытом

                        Что вы? Не было, конечно. Ещё у них не было проблем с архитектурой, паттернами, тестами, да вообще ни с чем не было. Прелесть разработки софта в самом начале 1980-х была в том, что ты мог выучить полсотни операторов выбранного тобой языка программирования, сесть, и начать писать. И у тебя будет получаться не особо хуже, чем у опытных разработчиков. И то, что получилось, вполне можно будет даже продать. Если ты был в США, а не в СССР, конечно.
                          +4
                          Я не думаю что проблематика такой сущности как FAT (активно просуществовавшей от того момента и до наши дней) была в изучении пол сотен операторов языка, и что эта ее реализация могла быть выполнена кем то без опыта.
                            0
                            Нет, конечно, не только в изучении операторов языка. Ещё надо было головой подумать, впрочем, как и всегда :) Но что у вас вызывает скепсис? FAT тех времён ничуть не сложнее, чем курсовые работы на ИТшных специальностях. Их же как-то пишут без опыта?
                            Да и кто разрабатывал FAT, это не секрет. Первую редакцию сделал Марк МакДональд, ему было тогда 21 год, потом усовершенствовал Тим Патерсон (тот, кто превращал QDOS в MS DOS), если не ошибаюсь, ему было 22, когда он этим занялся.
                              0
                              Вы помните жесткие диски тех времен? Сколько например в % битых секторов могло присутствовать в норме на абсолютно новом диске?! Сколько могло появится в процессе эксплуатации?! FAT тех времен — на абсолютных дровах работала! Многие поздние ФС таких дров даже в жизни не видели — и проектировались по совсем другим принципам в совсем другом мире…

                                0
                                Отлично помню. Как правило, на новых дисках могло быть несколько битых секторов, но их количество измерялось в штуках, от 0 до максимум десятка, а не в процентах. А ещё прекрасно помню, как в FAT реализован механизм защиты от подобных сбоев. DOS вызывает функцию форматирования сектора из BIOS, та форматирует сектор, и если контроллер накопителя при выполнении операции выдаёт отказ, DOS записывает в соответствующий кластер в FAT байт с кодом, указывающим, что кластер с этим сектором сбойный. И впоследствии при записи файлов этот кластер будет пропускаться.
                                Сложнейшая логика, да? Байт аж на десять. А то и целых пятнадцать. И проектировалась, наверняка, несколько месяцев.
                                  0
                                  Вы смотрите отсюда назад во времени. Вам кажется, что какие то вещи чрезвычайно просты, когда о них вы читаете в книжке. Но вот на момент создания, это было на самом деле сложнейшей логикой. А за 10ю байтами могли стоять месяцы проектирования и исследований. И было совсем не очевидно, как себя в реальности ведут эти диски и что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки.
                                    0
                                    Вы смотрите отсюда назад во времени.

                                    Я не вчера родился. Я моложе Билла Гейтса, но старше MS DOS :) И мне довелось под неё попрограммировать ещё тогда, когда это не было некромантией.
                                    Но вот на момент создания, это было на самом деле сложнейшей логикой

                                    Вы так плохо думаете о программистах 1970-х годов? Напомню, на момент создания MS DOS уже без малого десять лет существовали на порядки более сложные Юниксы, а также IBMовские OS/360 и т.д., многозадачные, с виртуальной памятью, разделением ресурсов.
                                    А за 10ю байтами могли стоять месяцы проектирования и исследований.

                                    Вы знаете, это сейчас, с нынешним диким спросом на ИТ-услуги, мы ухитряемся тривиальный код делать так, что работа на день растягивается на месяцы проектирования и исследований. А в те годы за такое бы у виска покрутили и сослали бы из программистов в лаборанты. Не было ничего подобного. Софт писался «как есть». Самым простым и очевидным способом.
                                    И было совсем не очевидно, как себя в реальности ведут эти диски

                                    Как написали в спецификации, так и ведут. Это была вообще не забота программистов файловой системы.
                                    что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки

                                    Знаете, что делает файловая система FAT в таких случаях? Правильно, ничего. Она ничего не знает о проблемах с диском и валится вместе с ним. Вы точно считаете, что они потратили месяцы проектирования и исследований, чтобы прийти к этому решению? :)
                                      0
                                      Я старше самого x86 и под досом тоже программировал. И точно считаю, что они потратили месяцы и решения там появились не просто так. И наверняка у них были варианты нормально не работающие. Потому, что подобные вещи никогда не проектируются на бумаге с первого раза.
                                        0
                                        Ну, вам наверное виднее. Лично я не способен узреть рокет сайенс в плоской табличке с кодами кластеров, при том, что четверть века назад мы, подростки, под влиянием «Думов» вполне успешно писали простенькие 3D-движки за несколько дней, владея только Турбо-Паскалем и школьными знаниями тригонометрии. И большинство из нас даже программистами не стали. Поэтому извините, но гипотеза, что чувак, работающий программистом в Майкрософт, на изобретение структуры FAT потратил более пары вечеров, сдаётся менее достоверной, чем гипотеза, что нас вывели рептилоиды с планеты Нибиру :) Особенно если учесть, что до появления FAT уже существовали и более сложные файловые системы, и более простые. И было с чем сравнивать.
                                          0
                                          Формат файлов MSWORD наверно вам тоже не кажется rocket science… Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)… А текстовые редакторы опять же имели ограничение памяти для работы в сегмент и менее и искали с воистину черепашьей скоростью.
                                            0
                                            Странная у вас логика, ей-богу. «Вы не едите жирное мясо? Наверное, вам не нравятся и помидоры?»
                                            Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)

                                            Вы же вроде как говорили, что вы взрослый дядька, старше IBM PC. Тогда вы должны помнить (или хотя бы знать), что IBM PC — единственный популярный компьютер с сегментной адресацией памяти, и всё, что было ДО него, имело линейное адресное пространство, и всякие WordPerfect'ы (появившиеся раньше MS Word'а) сегментных ограничений на своих платформах не имели. Кроме того, формат файлов RTF появился аж в 1987-м году, а более знакомый нам бинарный формат — вообще в 1990-е. То есть это вообще другая эпоха.
                                              0
                                              CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще и свалка состояла из еще более мелких файлов, и MS-DOS это все тупо наследовал.
                                                0
                                                CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще

                                                Надо ж понимать, что это не свойство CP/M, а свойство тех компьютеров, на которых она работала. Хотя для домашних компьютеров 1970-х это и так был огромный объем памяти. Но компьютеры 1970-х не заканчивались машинками на MOS 6502 и i8080, были ведь и профессиональные архитектуры.
                                                MS-DOS это все тупо наследовал.

                                                Наследовал. Кстати, как и структуры файловой системы CP/M. Там она, правда, была основана на экстентах, но структуры корневого каталога и FCB оттуда перекочевали в FAT. По сути, изначально заменили только таблицу экстентов на таблицу кластеров.
                            0
                            И надо заметить, что вояджер до сих пор летит без синего экрана смерти.
                              +2
                              У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы. Тогда люди меньше времени тратили на болтавню в бложиках (за их отсутсвием) и больше на научную раборту. Вы наверное не былвали в технических библиотеках, после которых возникает улыбка от того что сейчас выдают за супер технологии. Ладно с узкой литературой, до которой доходят не многие, но например Кнут, которого знают даже школьники, писал в середине 60х. Не надо думать что раз тогда архитектура ПК была 16 битной, и только все начиналось (для ПК) то и писали код люди без опыта, у них была куча опыта и знаний, которые они получали на более серьезных архитектурах. А ограничения в вычислительных возможностях заставляли отпимизировать все и вся, так что там вполне есть чему поучиться.
                                0
                                У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы.

                                Я вас немного верну с небес троллинга на землю. То, что я (и другие специалисты) считают современными паттернами разработки, имеют вполне определённые даты появления. Первая публикация была в самом конце 1980-х. TDD — тоже детище 1990-х.
                                А Дональд Кнут в своих трудах описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.
                                  0
                                  описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.

                                  Именно по этой причине базы данных занимаю террабайты, а программа рассчитывающая коэффициенты экспоненты по набору точек работает минуты на современном ПК, хотя на 8086 данные убирались в мегабайты, а расчет длился секунды.
                                  Но им это не понадобится.
                          +1
                          Последний проект, где я видел обширное применение ассемблера, это openssl.
                          Причём ассемблер вполне там оправдан. Я сравнивал с ассемблерные реализации SHA256 и AES с сишным кодом в полной оптимизации на clang и gcc. Ассемблер оказался на 15% быстрее.
                          Но поверьте мне, этот код довольно далеко уехал от кода тридцателетней давности.
                          Если вы хотите писать быстрый код на ассемблере для x86_64, то надо не учить древний MS-DOS, а изучать архитектуру современных процессоров.
                            0
                            Понятно, что x86 в чистом виде практически не актуален. Но ведь с нуля начинать писать под core i7 задачка та еще. Если изучать ARM-ы, то там весьма приличный зоопарк. Тут же возможность быстро усвоить принцип и даже что-то легко попробовать (в том же dosemu). Да просто создание .com файла это гораздо более быстрый путь к чему-нибудь работающему на asm, хотя бы из-за того что не надо сразу же разбираться с заголовками.
                              0
                              Не понимаю какие именно принципы можно изучать. Я сам в детстве на уроке информатики программировал в фаре, ввода бинарные опкоды команд альтом, пока другие изучали ворд. Да, это весело и интересно, но не стоит питать иллюзий, что это даст какие-то навыки, которые можно применить в современном программировании.
                              А если хочется разминки для ума, то есть много более интересных платформ, например почему бы не программировать z80?
                              Да и под x86 реальный режим есть много очень крутого и интересного кода для вдохновения: исходники дума и других игр, известные демки особенно 256 компо и т.д.
                                0
                                > Не понимаю какие именно принципы можно изучать.

                                Адресация памяти, устройство стека, загрузка выполняемых модулей, выполнение условных переходов на уровне железа, доступ к оборудованию, обработка прерываний, работа с регистрами, в конце концов чтение дизасемблированного кода. Я думаю например все это можно изучать.

                                > почему бы не программировать z80?
                                z80 тоже хороший вариант, но исходников OS под z80 недавно не открывали. Я думаю это надо не противопоставлять, а считать что одно дополняет другое.
                                0
                                Если изучать ARM-ы, то там весьма приличный зоопарк.
                                «Зоопарк» там — на уровне аппаратной реализации взаимодействия с оборудованием. На прикладном уровне ничего страшного в arm'ах нету и изучается он проще x86. (Неспроста же наиболее дорогие микроконтроллеры основаны на ARM-ядрах.) Впрочем, для сомневающихся есть ещё более простой MIPS.
                                  0
                                  А вы сначала изучили arm или x86?

                                  > На прикладном уровне ничего страшного в arm'ах нету

                                  Вы о системе комманд и оптимизациях? Или о чем?
                                    0
                                    Сначала прослушал дебильный курс по созданию *.com-файлов с помощью tasm.exe. Сначала рассказывали про регистры общего назначения AX, BX, CX, DX, потом про указатели на сегменты данных, кода и стека, потом говорили про регистр флагов, который можно только прочитать, и в который нельзя писать. Потом какую-то муть про разницу между прерываниями BIOS и прерываниями DOS. И никто не объяснял, зачем вообще всё это дерьмо надо, когда 16-битный код используется разве что в старых играх, а агрегатами на производстве управляют микроконтроллеры, у которых всё совсем по-другому.

                                    А потом появилась такая очень популярная доступная «игрушка для мальчиков» — Palm Zire 21. Которая, несмотря на свои 2МБ памяти была мега-популярной, и кто дружил с паяльником, ковырялись в ней как могли. Помню, была даже такая программа, которая показывала время, оставшееся до конца пары всё увеличивающимися цифрами, и последние 10 секунд показывались во весь экран. Я тогда с паяльником ещё не подружился :( а литературы по ассемблеру для arm не было почти нигде (зато Фигурнов продавался в каждом газетном киоске). И некоторые сдавали зачёт по ассемблеру, демонстрируя работу кода на своих пальмозаврах, а остальные только с завистью смотрели.

                                    Ну а сейчас есть ресурсы (этот, и на английском и даже кто-то в песочницу тут пишет), как кодить на ассемблере для Малинки. Что позволит решать очень много интересных задач, и зоопарк пугать не должен.

                                    Изучение ассемблера х86 — зря потраченое время, если конечно ты не собираешься посветить свою жизню системному програмимрованию и написанию загрузчиков и бут-менеджеров.

                                    А я пока понемногу мучаю свою Бананку М2.
                                    Вы о системе комманд и оптимизациях?
                                    О системе команд разумеется.
                                      0
                                      > А вы сначала изучили arm или x86?

                                      Извините, что влезаю — вот я, например, сначала изучил S/360, PDP-11 и 6502. Уже после этого был x86.
                                      И согласен с выводом — ARM проще. А, кроме того, он ещё и современнее. X86 это совершенно адская смесь решений, в которых смотрят даже не на один шаг вперёд, а на полшага, а потом мечутся в совершенно другую сторону, и легаси, хвосты которого растут ещё из 70-х, а два шанса переделать на нормальные были, цензурно говоря, пропущены.

                                      > Вы о системе комманд и оптимизациях? Или о чем?

                                      Я бы сказал, обо всём.
                                  0
                                  Применение ассемблера в любой реализации AES оправдана только тем, что под него существует свой набор инструкций… Очень глупо его не использовать — это же отдельные затраты на куске кремния…

                                  Сравните например несколько реализаций древнего DES — от битности в них только косметическиe изменения.

                                  Опять же я например не вижу, зачем можно было бы писать быстрый код на x86_64. Какие то там буквально единичные приложения типа hashcat — и все…
                                    0
                                    Для AES-NI ассемблер не очень-то и нужен, там есть интристики.
                                    Но не у всех алгоритмов есть хардварные реализации. И их можно реализовать на нативном ассемблере быстрее, чем это делают современные оптимизирующие компиляторы. Это сложно, муторно, требует знаний работы железа, но в результате это может дать вполне ощутимый профит.
                                    И конечно же, для такой работы никак не пригодится вдохновление ассемблерным кодом древнего доса.
                                      0
                                      Во времена пентиумов-4 или атлонов тот же mplayer с ассемблерными вставками позволял играть DivX без дрыганья.
                                        0
                                        А 99% других программ не позволяли — и это массово не прижилось…

                                        Новый ренесанс возможен будет после нескольких долгих лет упора в кремний… Когда маркетологам надо будет хоть что то предложить для понижения потребления-повышения производительности…
                                          0
                                          Новый ренесанс возможен будет после нескольких долгих лет упора в кремний…

                                          Могу только добавить, что даже у кремния есть ещё запас на много лет по оптимизации. Не за счет уплотнения техпроцесса, а за счет усовершенствования «схемогенераторов» а-ля Verilog, или ручной оптимизации.
                                            0
                                            Это просто отсрочка — а еще в аккумуляторах может свершится какой нибудь прорыв… но все равно в конце концов мы придем к тому, что надо будет избавится от любого лишнего исполнения кода в бекграунде мобильных устройств — а ассемблер останется единственным методом это сделать.
                                              0
                                              Как альтернатива — ML в оптимизациях кода.
                                                0
                                                Надеюсь к тому времени ручное написание кода будет забыто как страшный сон. И соответственно ML там нафиг не нужен будет.
                                    0
                                    Сам код — показать не смогу но проект написаный на АСМ-е вполне себе комерческий и современный — могу
                                    avidis.ua/files/Spotter-manual.pdf
                                    Вот эта штука целиком написана на АСМе. Размер дистра с инсталятором — 1.5Мб (без справки)
                                      0
                                      Спасибо — даже в таком виде интересно будет посмотреть.
                                    +2
                                    Изучал в универе асм как раз на 16-битном x86. Когда захотелось пописать что-то под Widnows, я не помню чтобы тратил время на изучение особенностей 32-битного кода — и так с ходу было всё понятно.

                                    Если цель изучения — понять как пишутся программы на любом из ассемблеров, то можно изучать хоть ассемблер процессора 6502 (тут может даже чем проще архитектура, тем лучше). А потом, когда все принципы усвоены — справочник по нужному процессору в руки (сами вы всё равно все тонкости всех инструкций вряд ли запомните), и в бой.
                                    0
                                    Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится.

                                    Если говорить о программе MASM (ml.exe), то научиться не получится, потому что современные версии сильно изменили синтаксис. В лучшую сторону.

                                    Исходники интересны в первую очередь как музейный экспонат. Примерно как утекшие исходники AWARD BIOS.
                                      0
                                      Синтаксис ассемблерного кода x86 задан в instruction manual на x86 — и его нельзя изменить в какую то сторону не изменив этот документ, а этот документ может изменить только разработчик — который не был бы тем кем он является если бы по желанию левой пятки менял его в какие либо стороны.

                                      Что там куда поменяли в современных версиях masm никому не интересно (у меня например 8-я стоит сколько себя помню).
                                        +1
                                        Попробуйте посмотреть, какой синтаксис генерят gnu-тулзы для х86 :)
                                          0
                                          AT&T? ну пусть — а какую задачу решает изобретение другого синтаксиса на тот же самый камень?!
                                          Не как у всех? как кому то там удобно? чтоб не платить кому то за что-то?
                                          — все это было не нужно, даже когда этого не было!

                                          Напомню, что средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно. Это только сейчас стало модно скидывать с себя любые задачи по написанию компиляторов на сторонние конторы.
                                            0
                                            AT&T-синтаксис достаточно похож на различных архитектурах — одни и те же символы обозначают регистр, непосредственное (immediate) значение, одинаковые псевдооперации; в итоге проще написать программу (компилятор), генерирующую текст на языке ассемблера под несколько различных архитектур, пригодный для подачи на вход в GNU assembler.
                                              0
                                              intel синтаксис так же похож на различных архитектурах надо ли говорить, что немалая часть архитектур интелом и придумана и синтаксис в каждой новой так или иначе наследовался — как и названия и назначения регистров, и в x86 есть команды из набора 4004, и расширение регистров из набора 8080. Тот же исходник для 8080 транслируется в x86 автоматически на уровне текста. В нем точно так же есть набор правил о том как записываются immediate и что за чем стоит. В итоге не существует какой либо сложности написать как программу компилятор ЯВУ в этот ассемблер (что было сделано ДО того как at&t придумала зачем то этот) так и компилятор этого (и любого) ассемблера в машинные коды (что вообще было сделано одновременно с появлением X86 в конце 70-х). Последнее — ну очень простая программа (представленная в данных исходниках образца 81 года).

                                              А вот с различными архитектурами — не получится. Потому, что на уровне ассемблера переносимости банально нет и быть не может! Следовательно ничего не мешает ему выглядеть в выводе как интел. Т.е. еще раз — «нафиг не нужен». Мало того замусорен, ибо префиксирует основной элемент текста (регистр), когда все нормальные префиксируют редко используемые элементы текста… Т.е. мало того, что велосипед изобрели — еще и колеса квадратные.

                                              0
                                              > Не как у всех?

                                              AT&T синтаксис является продолжением синтаксиса ассемблера Unix для PDP-11 и VAX, отсюда и специфика построения (например, знак % как префикс регистра, или приёмник последним). Возник он при переносе Unix на x86, и авторов этого процесса меньше всего волновала совместимость с синтаксисом Intel.

                                              > средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно.

                                              Intel и Microsoft они таки были платными. И википедия подтверждает — «were sold» и т.п., а не просто раздавались. И в общем случае развитие шло от того, что средства разработки от поставщика все были платными, к тому, что платные версии вытеснялись всякими GCC, GAs, binutils и т.д., и тогда производитель становился вынужден делать своими версии бесплатными.
                                                0
                                                Для того чтоб заявлять, что что то кем то вытеснялось — поищите хотя бы целевую аудиторию, для этих средств вытеснения… (пишущую на линуксах на x86 ассемблере)…

                                                Так вот кроме пары гиков делающих это чисто по приколу и пары каких нибудь разработчиков кодеков, которые скорее всего текстовым перепроцессором получают результаты своей писанины напрямую из интеловских кодов — вы их не найдете. Потому что ни один специалист не будет учить 2-й велосипед идентичный первому на уровне функционала. В то же время существует 10-к огромных community пишущих в intel синтаксисе под win.
                                                  0
                                                  > Потому что ни один специалист не будет учить 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 и тому подобные места — ничуть не гики, а взрослые люди, понимающие ответственность за проект, которым пользуется вся планета.
                                                    0
                                                    Вы фундаментально путаете понятие «специалист» и понятие «человек который в курсе как бывает и что то где то видел»… Специалист — это тот кто на этом ПИШЕТ причем ручками (т.е. можно увидеть им написанные результаты и вывести статистику), а не тот кто в курсе «как оно там бывает»… А пишущих в at&t относительно пишущих в intel-е в реальном мире и в бинокль не видать. Опять же зачем в GNU СЕЙЧАС вдруг возник интеловский синтаксис — если по вашему все так хорошо с at&t-шным из тогда? Признали ошибку или что — хотят притянуть реальную аудиторию которой не нужен цирк с чуждым процессору синтаксисом?
                                                      0
                                                      > А пишущих в at&t относительно пишущих в intel-е в реальном мире и в бинокль не видать.

                                                      «В реальном мире» вообще пишущих на ассемблере не видать, а я таки вижу людей, которые пишут и именно на AT&T.
                                                      Какой именно мир для вас реальный — понять сложно. Если мир Windows, то согласен, там таких будет исчезающе мало. Но для меня сам этот мир это какая-то соседняя галактика, наблюдаемая только в телескоп.

                                                      > Опять же зачем в GNU СЕЙЧАС вдруг возник интеловский синтаксис — если по вашему все так хорошо с at&t-шным из тогда?

                                                      Опять передёргиваете, я ни слова не говорил про «всё хорошо». Я говорил, что проблемы не настолько существенны, чтобы от него отказываться.

                                                      > Признали ошибку или что — хотят притянуть реальную аудиторию которой не нужен цирк с чуждым процессору синтаксисом?

                                                      Настоятельно прошу не подменять понятия. Процессору любой синтаксис ассемблера чужд, как и сам ассемблер. А так — да, потребность в Intel синтаксисе оказалась заметной просто из-за его использования в соседних подотраслях.
                                                      Для других архитектур подобного не происходит (что подчёркивает, что специфика в Intel, а не в чём-то ещё).
                                                        0
                                                        «В реальном мире» вообще пишущих на ассемблере не видать, а я таки вижу людей, которые пишут и именно на AT&T.

                                                        Вот тут по ходу обсуждения обнаружилось аж целое ОДНО коммерческое решение на ASM под win (хотя их не мало). А где можно на этих ваших «людей пишущих в синтаксисе at&t» посмотреть?

                                                        Но для меня сам этот мир это какая-то соседняя галактика, наблюдаемая только в телескоп.

                                                        Учитывая, что это 90+% рынка десктоп ос — вы телескоп то правильной стороной разверните — а то поле зрения сужено слишком…

                                                        Процессору любой синтаксис ассемблера чужд, как и сам ассемблер

                                                        Это не подмена понятий — разработка синтаксиса ассемблерных команд задача не много проще, чем разработка самого процессора. И удачные синтаксисы увы встречаются очень не часто. И возникают они не просто так — за ними стоят огромные наборы очень серьезных правил как лингвистики так и логики и специалисты в этих отраслях. Поэтому и нельзя вот так по желанию левой пятки взять и создать «свой синтаксис с блекджеком и тп...».
                                                          0
                                                          > Вот тут по ходу обсуждения обнаружилось аж целое ОДНО коммерческое решение на 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, разная провайдерская автоматизация, управлялки железом… какого молота я на вашем десктопе высерплю и зачем мне что-то разворачивать?

                                                          > разработка синтаксиса ассемблерных команд задача не много проще, чем разработка самого процессора.

                                                          Простите, я это не могу воспринять иначе как странную шутку. Синтаксис ассемблера, при наличии готовой системы команд — задача студенческого уровня.
                                                          Если хотите возразить — приведите хотя бы пару проблем, которые встречались в этой теме и для которых нужно было провести действительно серьёзную исследовательскую работу.
                                                            0
                                                            Оно целиком на ассемблере? Или всё же какие-то ключевые моменты?

                                                            Насколько я могу судить по объему кода и функционалу — оно целиком!
                                                            Да полно вокруг. Просто обычно в нашем мире это выглядит как библиотека (чаще опенсорсная), в которой некоторый набор критичных по скорости элементов написан на ассемблере


                                                            Про криптографию сразу забудьте. Ну не имеет никакого отношения к программированию на ассемблере то, что вы взяли самую оптимальную реализацию AES на x86 ассемблере, которой лет столько же сколько самому AES (и еще одну параллельную которой чуть меньше — на наборе инструкций AES) и над которой работали по сути единичные личности один раз в жизни — а дальше начали ее транслировать из синтаксиса в синтаксис и таскать из проекта в проект, и перебивать там по мелочи для того, чтоб из closed source сделать ее open source и еще раз, чтоб наоборот, с каждой итерацией этого цирка делая только хуже (потому что там других вариантов нет — эти вещи когда один раз нормально пишутся на ассемблере — каждый такт считают и каждый метод по 3 раза обдумывают — и любые переписи их только портят)…

                                                            Опять же GRUB — это я так понимаю речь о куске сектора в 512 байт в 16-ти битном коде которому 100500лет и который не позволяет сдохнуть как классу 16-ти битным компиляторам (но скоро сдохнет ибо uefi же)? ну да — много людей наверно денно и ночно его пишут, учитывая, что там с начала существования grub ничего не менялось…

                                                            И останутся у вас таким темпом только кодеки и странные закрытые библиотеки из непонятных дров. И придете вы к двум с половиной гиков. А уж в юзерспейсе в линуксе ассемблера вообще не существует. (в виндах — есть).

                                                            Простите, я это не могу воспринять иначе как странную шутку. Синтаксис ассемблера, при наличии готовой системы команд — задача студенческого уровня.


                                                            Никогда нельзя поручать студенту работу профессионального лингвиста — иначе получаются такие выкидыши дилетантов, как наборы AVR и microchip инструкций. Язык — это очень сложная штука и в нем очень легко налажать. Это не просто текст — это архитектура и это восприятие. Если мнемосхема логична, а код правильно структурирован, нормально выровнен, и имеет разделение оператор-операнды, выбран правильный шрифт и на дисплее строго определенный объем информации — достаточно буквально одного короткого взгляда на страницу текста, чтоб мгновенно понять, что именно этот код делает. Ни один приближенный к естественному язык программирования не дает такой возможности. Потому что вам надо в каждой строке 100500 раз думать, что там в какой последовательности выполняется. в ассемблере выполняется без вариантов сверху вниз. Кроме того система должна быть спроектирована на будущее — т.е. необходимо не просто выстроить логичную схему мнемоник, но и понимать как в эту схему могут добавляться мнемоники которых сейчас еще нет но они будут. Была поучительная история, как раз с интелом в виде скачка с тупиковых мнемоник 8080 (по критерию меньше текста лучше и инклюзивные операторы-операнды) к продуманным и расширяемым Z80 Фейджина (лучше больше зато логично и последовательно, операторы и операнды разделены в столбцах), в интеле просто не дураки сидели и смогли понять где именно они налажали и почему 8080 довольно хреново продавался и код к нему писался не очень. Тогда они отказались от текстовой совместимости в пользу транслятора и все придумали заново! Потому, что если бы в интеле ТОГДА в конце 70-х этого бы не поняли своей ошибки — сейчас бы скорее всего мы жили в другом мире, с совершенно другой архитектурой ПК на вашем столе. Вот вам один пример той самой серьезной исследовательской работы — которая по сути изменила мир через 30 лет.
                                                              0
                                                              > Про криптографию сразу забудьте.
                                                              > Опять же GRUB

                                                              Простите, а чего вы вообще хотели, прося примеры на ассемблере? Чтобы толстый объёмный проект был целиком на нём написан, развивался и поддерживался во всех деталях? Ну так времена, когда так делали, закончились лет 30 назад. Конечно, есть отдельные случаи (раз, два и т.п.), но они погоды не делают. Все стараются сделать небольшое количество переходников там, где без них не обойтись, или вылизывать таки особо критичные места.

                                                              > И придете вы к двум с половиной гиков.

                                                              А мы и так к ним давно пришли. Всё остальное, кроме тех же особых мест, пишется на уровне не меньше чем переносимый ассемблер по имени «C».
                                                              Ибо незачем делать иначе.

                                                              > и почему 8080 довольно хреново продавался и код к нему писался не очень

                                                              «Товарищ, фантастика на втором этаже» ©

                                                              8080 потерял преимущество в пользу Z80 по причинам:
                                                              • Одно напряжение питания +5 (вместо трёх).
                                                              • Реально полезные новые команды (а не просто мнемоники), больше регистров.


                                                              Это говорят все, кто их сравнивал. Я не могу в этом лично участвовать, у меня в то время в working set были PDP-11 советского исполнения и 6502 на «Агате». Но знакомых, которые сами паяли всякие синклеры, Радио-86 и т.п. — около десятка, и их мнение тут единодушно. Как именно писалась какая-нибудь SPHL или MOV SP,HL — для них имело десятое и двадцатое значение.

                                                              В общем, не годится пример :) Ещё есть?

                                                              > как наборы AVR и microchip инструкций

                                                              А что вам не так в синтаксисе AVR? ;)
                                                                0
                                                                Простите, а чего вы вообще хотели, прося примеры на ассемблере?


                                                                Людей я хотел. Который пишут сейчас. А не куски кода написанные в 90-х типа AESа и 16-ти битного загрузчика который туда сюда таскают по проектам, размахивая им как флагом.

                                                                SPHL или MOV SP,HL — для них имело десятое и двадцатое значение.


                                                                Потому, что они просто слаще меда ничего не едали. И кроме SPHL ничего в жизни не писали. И им тогда совсем не очевидно было, что в будущем регистровых пар которые можно будет положить в SP, будет несколько больше, чем одна, и что записи MOV SP,HL эволюционировавшей в MOV RSP,RSI (x86-64) скоро стукнет 40 лет и даст бог — мы еще в раю будем так писать, а их SPHL через 5 лет просто сдохнет.

                                                                А что вам не так в синтаксисе AVR? ;)

                                                                Да это же классический идиотизм вида «1 действие — 100500 мнемоник» — та же SPHL вид сбоку, причем во времена когда был доступен анализ чужого опыта в огромном объеме — короче в очередной раз задачу лингвиста решают какие то студенты.

                                                                  0
                                                                  > Людей я хотел. Который пишут сейчас.

                                                                  Они есть. Знаю лично. Но их один на сто тысяч. И больше и не нужно.

                                                                  > и что записи MOV SP,HL эволюционировавшей в MOV RSP,RSI (x86-64) скоро стукнет 40 лет и даст бог — мы еще в раю будем так писать, а их SPHL через 5 лет просто сдохнет.

                                                                  Ничто не мешает вести несколько параллельных мнемоник, если старая перестала удовлетворять. Это не проблема типа «int a» против «var a: int», которая действительно заслуживает внимания и порождает современные ситуации типа Most vexing parse.

                                                                  Кстати, в регистрах вы ошиблись — HL это BX, а не SI.

                                                                  > короче в очередной раз задачу лингвиста решают какие то студенты.

                                                                  Если речь про SPHL — они всё правильно сделали. Когда таких команд было только две — такая мнемоника была выгоднее. Ну и снова — синонимами решается банально.
                                                                  Если в AVR что-то не понравится, можно выкрутиться так же, хотя по-моему там этой проблемы совсем минимум.
                                                                    0
                                                                    Ничто не мешает вести несколько параллельных мнемоник

                                                                    Ну черт возьми зачем в реале нужен этот фирменный линуксовый велосипед? (равно как опен офис-гимп-и вот это все).

                                                                    короче суть я понял — вы знаете целого одного человека который пишет в этом синтаксисе и целых штук 5 оригинальных проектов если исключить туда сюда таскуемую криптуху и столетний загрузчик — несомненно изобретение нового синтаксиса — того стоило!

                                                                    Кстати, в регистрах вы ошиблись — HL это BX, а не SI.
                                                                    Конечно — я уже и не помню даже правил транслятора 8080>8086 мне почему то казалось он SI использует в этом случае — да и пофигу — все это мертво.

                                                                    Когда таких команд было только две — такая мнемоника была выгоднее.

                                                                    какие в AVR две!?
                                                                    там сразу с десяток.
                                      –2
                                      Ааа Brown Interrupt List! Закапайте обратно :)
                                        +4
                                        Нечего капать, у окулиста атропин кончился.
                                        +1
                                        Вот тут пытаются из «этого всего вот» собрать рабочую систему
                                        virtuallyfun.com/wordpress/2018/09/29/ms-dos-v1-25-and-v2-0-source-code-now-on-github/#comments
                                          0
                                          Код явно не полный. По крайней мере в 1.25 не хватает очень большого количества файлов.
                                            0
                                            На c#? ;)

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое