Comments 117
которые будут нести свою шаблонную ахинею про то, что QBasic/QuickBasic и (тут особенно обидно) Visual Basic, дескать, недо-инструменты, потому что не умеют в компилирование, а умеют лишь интерпретировать исходный код.
Спасибо за исследование, но я всё-таки был прав. Компиляция в нативный код в Visual Basic появилась только в VB5, до этого он EXE собирал из исполняющей среды и исходников, точнее, не исходников, а байт-кода, в который он их преобразовывал.
Тогда любой современный компилятор можно назвать интерпретатором.
А если вспомнить, что в любом x86 современном процессоре встроен преобразователь cisc команд во внутреннее risc, то можно дойти до того что ни один язык не является компилируемым.
На самом деле у компилятора и интерпретатора есть коренное различие. У второго ошибка синтаксиса языка - ошибка времени исполнения программы. При компиляции анализ на корректность синтаксиса происходит на этапе сборки программы.
EXE собирал из исполняющей среды и исходников, точнее, не исходников, а байт-кода,
Обычно говорят «точнее», когда хотят уточнить и без того достаточно точное первое утверждение. Например «она была зелёного цвета, точнее фисташкового». Его странно видеть в предложениях типа «он был чёрным, точнее белым» и т.п.
Исходники и байт-код — на двух диаметрально противоположенных концах жизненного цикла программного продукта. Это руда и экскаваторы. Мука и булочки.
Если вы понимаете, что там не исходники, а байт-код, то почему называете это «интерпретируемым языком»? Точно так же работает дотнет, точно так же работает Java. Никто не говорит, что Java интерпретируемая, что C# интерпретируемый, что VB.NET интерпретируемый.
Python, PHP и современный JS тоже генерирует байт-код и выполняют его на своей виртуальной машине. Но они это делают в момент запуска и на конечном устройстве. В случае VB это было делалось один раз, при компиляции и происходило на машине разработчика.
появилась только в VB5, до этого он
Даже если бы до появления VB5 там реально вшивался бы исходный код (что not the case, как мы выяснили, исходный код не вшивался никогда), почему-то никто никогда не делает эту ремарку с указанием версии, хотя, грубо говоря, 10 лет генерации нативного машинного кода не было, после чего 20 лет эта генерация была — то есть она была бОльшую часть времени, но этого факта как будто бы не существует, зато положение дел, которое существовало меньшую часть времени, акцентируется и извращается до непомерных масштабов (готовый оптимизированный байт-код для виртуальной машины выдаётся за исходный код).
Исходники и байт-код — на двух диаметрально противоположенных концах жизненного цикла программного продукта. Это руда и экскаваторы. Мука и булочки.
Нет, вообще нет. Байт-код, это нечто посередине между исходниками и машинным кодом. Промежуточный набор инструкций, который получился после того, как отработал парсер синтаксиса, но ещё не пригодный для исполнения на целевой машине. Чтобы он исполнился, нужен либо
Собственно компилятор, который соберёт пригодный для исполнения машинный код
Среда исполнения с JIT-компилятором, которая будет собирать пригодный для исполнения машинный код прямо перед выполнением конкретных подпрограмм.
Интерпретирующая среда исполнения, которая будет читать байт-код и медленно и уныло исполнять это по шагам.
Так вот, классический VB - это как раз третье.
хотя, грубо говоря, 10 лет генерации нативного машинного кода не было, после чего 20 лет эта генерация была
Первая версия VB вышла в 1991, генерация появилась в 1997, последняя версия вышла в 1998. Он не так долго успел побыть зрелым инструментом разработки, чтобы это вошло в историю.
Медленно и уныло — это как раз второй вариант.
С какой стати 3-й вариант медленный и унылый? Пруфы? Доводы?
Первая версия VB вышла в 1991, генерация появилась в 1997, последняя версия вышла в 1998. Он не так долго успел побыть зрелым инструментом разработки, чтобы это вошло в историю.
Я что-то не понял: когда в 1998 вышла последняя версия, возможность компилировать в Native-код убрали? Да? Нет. В 1998 ничего не изменилось. Поэтому на временной шкале если и отмечать точки переломных моментов, то 1998 год как точка явно вообще не должен был отмечен.
Я что-то не понял: когда в 1998 вышла последняя версия, возможность компилировать в Native-код убрали? Да? Нет. В 1998 ничего не изменилось.
Конкретно в 1998 ничего не изменилось, но я нигде и не писал, что что-то в 1998 изменилось. Изменилось чуть позже, в 2001-м, когда вышла новая платформа, более не совместимая со старой, а Майкрософт дала понять, что VB - продукт теперь устаревший, и пора мигрировать.
Изначальная Жаба, насколько помню, была двухстадийной: первая стадия -- это компилятор из исходного текста в байт-код, а вторая стадия -- это интерпретация байт-кода (именно интерпретация). Более поздние реализации -- тоже двухстадийные, но второй стадией является уже компиляция байт-кода в машинный код, но только тогда, когда это понадобилось (компиляция прямо во время выполнения по мере необходимости). Но, естественно, принципиально нет проблем компилировать жабу сразу в машинный код -- но тогда не получится распространять жаба-программы в типа готовом виде, а только в виде исходников.
Что же до Бейсика, то, хотя классические (именно классические, 70-х годов) диалекты сего языка почти всегда интерпретировались, технически они могли и компилироваться. И компиляторы таки были уже тогда; скажем, под RSX-11 на PDP-11 был интерпретатор одного диалекта Бейсика и компилятор совершенно другого диалекта, не совместимого с первым (ну, принт хелловорлд и там, и там будет работать одинаково, но вот практически всё остальное было очень разным).
Я видел сам неоднократно бейсиковые блобы в бинарнике в школьные времена, до того как перейти на паскаль и буквально месяц два назад натыкался на каком-то ретро канале на ютубе на тоже самое. Будет время, проверю в досбоксе.
Единственное в чем может быть заквоздка, это в том что я имел ввиду qbasic из состава DOS, возможно это другой продукт
QBasic вообще не делал EXE-файлы.
QuickBasic делал, и это были настоящие полноценные полноправные EXE, как показано в статье.
Я тоже отчётливо помню фейковые «ЕХЕ» с явно видимым исходным васичным кодом внутри. Причём они работали с точно такой же скоростью, что и просто васик.
Смутно помню, что при каких-то обстоятельствах получил код, летающий птичкой. Что-то ещё в голове промелькнуло, типа «о, начали реально компилировать, а не просто цеплять в хвост интерпретатору бейсичный код». Не был уверен в том, что правильно запомнил — но тут автор, похоже, подтвердил в своей статье то, что мне это не померещилось и память не переврала.
Ну, теперь подожду подтверждения первой части воспоминаний с Вашей стороны :) Будем искать, в какой момент произошла эта разница :)
Может быть потому что Quick Basic мог сохранять исходники в своём бинарном формате?
в начале девяностых как-то попалась в руки демо версия довольно крутого по тем временам SPICE симулятора электронных схем, написанная на каком-то тогдашнем компилируещем бейсике. Все модели, символы и формулы были в комплекте, а демонстрационность реализовывалась тем что они вырезали логику ввода от пользователя и заменили на массив записанных комманд симуляции - движения мышью, нажатия клавиш итд. Помнится, я наверное пару недель пытался сломать этот код и переделать в более-менее употребимое состояние, но так и не смог, что-то он там слишком сложное для понимания накомпилировал, так обидно было. И 640кб памяти катастрофически не хватало, не влазило это всё туда вместе с дебаггером, но это всетаки удалось решить дополнительной EGA карточкой, подключал её память в дос как расширенние, всетаки влезло, хотя и не помогло в итоге. Своеобразные впечатления...
В те годы интерпретатор был слишком дорогим удовольствием.
Да, включите логику и объясните каким образом это дорогое удовольствие было в каждой 8ми битке, например в ZX80 с 4КБ памяти и сколько там, 16КБ ПЗУ ?!
Не жалко занять всю имеющуюся память интерпретатором, если по изначальной задумке это единственное, чем должно быть занято ПЗУ вашего изделия.
Пзу занимается много чем, речь ведь идёт о компьютере. Там куча системных функций зашита, особенно в случае ZX, в котором не было ни одного спец контроллера. Системный шрифт и прочие ресурсы.
Не жалко занять всю имеющуюся память интерпретатором
Еще один миф, интерпретатор копактнее нативного кода. Есть техника token threading или еще "p-code" называется. Инструкции могут 4 бита занимать, вызов функции 8 или 12 бит. Нативный вызов минимум 8 на иснтрукцию + 8 адрес.
Я не понимаю, с чем вы вспорите? Если вы предлагаете рассмотреть гипотетический вариант, где исполняемый файл содержит в себе прикладной код программы, представляемый в виде 4-битных элементов, полученных путём предварительной обработки исходного кода в момент компиляции, а также исполняющий системы, которая бежит по этой цепочке 4-битных элементов, то это не по адресу, потому что я не про такой подход говорил, что он дорогой до ресурсов. Нет смысла оспаривать то, чего я не говорил.
Я говорил, что что интерпрератор, который в момент выполнения прикладной программы будет интерпретировать исходный код прикладной программы с нуля, с сырого человеко-читаемого представления — вот он будет и медленный, и объямный по памяти.
Опять, когда вы говорите про 4-бита, про 8/12 на функцию — вы говорите о компактности представления пользовательского кода, а я говорю о [не-]компактности machinery, которая всё это делает.
Кстати в случае с ZX Spectrum, в нём исходник фактически уже был частично токенизирован: в памяти вместо ключевых слов лежали однобайтные коды этих слов.
Поэтому, например, вместо FOR a=1 TO 10 STEP 2 в памяти лежало EB 61 3D 31 CC 31 30 CD 32 — интерпретатору требовалось распарсить только имена переменных и литералы. Это сильно упрощало интерпретацию и требовало существенно меньше памяти, чем иные промежуточные структуры.
Если быть точным, то рядом со всеми этими 31, 31 30 лежали ещё 0Е aa bb cc dd ee, то бишь дополнительно к текстовому представлению числа хранилось ещё и внутреннее численное, что память не экономило. Но слегка, видимо, ускоряло (но вряд ли сильно, математический движок или "калькулятор" там был очень тормознутым).
в ZX80 с 4КБ памяти и сколько там, 16КБ ПЗУ ?!
Не 4, а 48 кб ОЗУ и 16 кб ПЗУ - самая распространенная версия
Спасибо, что включили мой username в свою статью. Прочтя Вашу статью я сильно озадачился - не выжил ли я из ума под старость лет, ведь в начале 90-х я имел дело QBasic и отчетливо помню, что никакой он не компилятор, но в Вашей статье приводятся ясные доказательства обратного. Чтож, надо разобраться. Я пошел гуглить и выяснил следующее:
Сущетсвуют целых три версии BASIC-а с похожими названиями от компании Microsoft: GW-Basic, QBasic и QuickBasic.
В состав MS-DOS сначала входил GW-Basic, с версии 5.0 его заменили на QBasic.
QuickBasic продвигался как отдельный продукт и действительно является компилирующим: содержит среду, компилятор, линкер и отладчик.
Ни GW-Basic, ни QBasic не являются компилятором.
Ниже цитата с сайте Wikipedia: https://en.wikipedia.org/wiki/QuickBASIC
A subset of QuickBASIC 4.5, named QBasic, was included with MS-DOS 5 and later versions, replacing the GW-BASIC included with previous versions of MS-DOS. Compared to QuickBASIC, QBasic is limited to an interpreter only, lacks a few functions, can only handle programs of a limited size, and lacks support for separate program modules. Since it lacks a compiler, it cannot be used to produce executable files, although its program source code can still be compiled by a QuickBASIC 4.5, PDS 7.x or VBDOS 1.0 compiler, if available.
Моя ошибка в том, что QBasic вообще не мог генерировать .EXE файл.
Страшная мысль: а вдруг это была неофициальная, но очень популярная тулза? И она нам всем запомнилась как вот это вот «ха-ха, оно не компилирует, просто цепляет васик в хвост файла»?
Надо б древние диски глянуть, вдруг прочитаются…
Это какой-то массовый психоз глюк в пространственно-временном континууме. :)
Эффект Манделы
Возможно. Но версия сторонней тулзы мне кажется более вероятной. BC она называлась, кажется. BC.EXE, не .COM.
Для BC.EXE гуглится, что так, собственно, назывался компилятор бейсика в версиях MS Basic PDS и MS Visual Basic for DOS: https://ftp.zx.net.nz/pub/archive/ftp.microsoft.com/MISC/KB/en-us/84/469.HTM И судя по этой документации, это именно что полноценный компилятор, а не склеивалка исходника с интерпретатором.
В состав MS-DOS сначала входил GW-Basic, с версии 5.0 его заменили на QBasic.
Если мне не изменяет память, в MS-DOS до версии 2.1 входил интерпретатор BASICA, который не был GW-Basic, и его функции зависели от версии MS-DOS
Если мне не изменяет память, в MS-DOS до версии 2.1 входил интерпретатор BASICA,
Не совсем, BASICA, это IBM'овский Бейсик, он в MS-DOS не входил, поставлялся только с ранними IBM PC DOS, и его основная часть была прошита в ПЗУ IBM PC, на других машинах он даже и не работал.
PC\MS это же просто нейминг. Входил конечно, в гите лежит https://github.com/microsoft/MS-DOS/tree/main/v1.25/bin
Он не просто был прошит, под него в оригинальном PC (model 5150) были отдельные панельки. Для кассетной версии они разумеется должны были быть заполнены ПЗУ в обязательном порядке, так как без них нельзя было пользоваться компьютером, а в версии с дисководами могли отсутствовать.
Интересный факт: многие БИОСы вплоть до 486 при отсутствии загрузочного устройства выдавали ошибку "Nonsense in BASIC"
Вот так было бы правильнее:
Вопрос трактовки слова "входил". МС свой дос простым смертным стала продавать только с версии 3.2 уже с GWBASIC.EXE, все остальное OEM-адаптации, будь то IBM или Compaq. Вот в IBM адаптации (включая 3.2-oem) это BASICA.COM - которому требовалось ПЗУ, а в Compaq portable это BASICA.EXE - ему не требовалось, но это по сути будущий GWBASIC
Там текст ошибки прои невозможности загрузки был немного другим: "No ROM Basic. System halted"
Моя ошибка в том ...
Ваш ответ напомнил мне высказывание Л.Н.Королева типа "своими ошибками надо помогать своим ученикам", он принимал у меня несколько экзаменов в свое время, случалось и плавать :)
ну хоть GWBASIC-то был интерпретатором?
Был еще такой MS Visual Basic for MS-DOS (VBDOS), я скачал его инсталляшку и запустил в DosBox.
В меню есть опция для генерации .EXE:
Я написал тестовую погу и заглянул в результирующий EXE. Если генерировать по второму варианту "EXE Requiring Run-Time Module", то получается коротенький файл похожий на "шитый код" в заголовке которого находится код подгрузки интерпретатора виртуальной машны из рядом лежащей библиотеки. Если выбрать первую опцию "Stand-Alone", то содержимое этой библиотеки включается в результирующий EXE, за которым следует все тот же "шитый код".
Как бы 3 этапа - разбор исходного текста - генерация промежуточного кода (p-code) - исполнение.
Можно p-code :
Не писать в файл и вообще не генерировать по AST в явном виде - 100% интерпретатор. Пример - классический бейсик.
Записать, и интерпретировать поочерёдно. Будет быстрее, т.к синтаксический разбор вычислительно непрост, но все равно это пошаговая интерпретация. Пример Forth - машина.
Записать и компилировать к исполнению в наивный только нужные куски - это JIT - компиляция, как Java или ранний .Net
Записать и компилировать полностью. Это компилятор. Например LLVM.
P-code соответственно называется немного по-разному - MSIL, Java byte code, LLVM IR, шитый код.
Как бы 3 этапа - разбор исходного текста - генерация промежуточного кода (p-code) - исполнение.
Это теоретизированный подход в духе «Как заработать миллиарды?»:
Придумать хитрый план
Начать работать по нему
???
Заработать миллиарды.
В случае VB/VBA промежуточных этапов и форм представления кода сильно больше, чем 3. Другой интересный факт состоит в том, что машинный код x86, когда он генерируется, не генерируется и P-кода, который при этом генерируется для работы проекта в режиме отладки (человек не произошёл от обезьяны, а человек и обезьяна происходят от общего предка)
Подробнее могу посоветовать только книжки по разработке компиляторов, я в три абзаца не уложился =)
Сам уже могу писать такие книжки ;-)
Ещё в школьные годы я разработал программный продукт, одной из фич которого было наличие встроенного ЯП и IDE (у меня он назывался XCode); это не было центральной фишкой той софтины, но это был как приятный бонус, как VBA в Excel — обычно вам должно хватить штатных возможностей Excel, но если вдруг не хватает, вы можете написать что-то нестандартное. За эту работу была получена золотая медаль Intel ISEF.
Проверить компилятор или интерпретатор проще по размеру бинарника или скорости исполнения. За базу по скорости можно взять аналогичный Паскаль или С код без оптимизации. Если драйстоун медленнее более чем в 10 раз, то это интерпретатор
В то, что visual basic настолько хорош, я узнал только от нашего общего знакомого лет 8 назад. До этого тоже был убежден, что там ни разу не натив. Хотя сам пишу на Си,Асм. Почему так - вероятно, общие дурацкие стереотипы, из каких-то статей для начинающих или холиваров, черт его знает..
Интересно другое:
Почему VB6 все же умер для M$,в плане, не получил развития далее? Фанатичная ставка на .NET?
Что думаете о проекте TwinBasic?
VB6 все же умер для M$
Ставка на dotNET
Сильная завязка на неудобные и сложные в разработке VBX, OCX
Так, для интереса, есть современный проект Xojo
VBX и OCX писать в одном месте вот так через запятую — это 5.
Это как сравнивать прерывания BIOS/DOS и WinAPI. VBX это устаревшая и узкопециализированная вещь. OCX — гениальная и крутая. Писать OCX на VB не неудобно и не сложно. Если вы собрались писать OCX на Си, это другой разговор, но в таком случае и реализовать дотнетовский элемент управления на Си будет ещё на пару порядков сложнее.
Думаю, что всё-таки внутри Microsoft всегда была предвзятость к VB как к побочному продукту существования VBA. Если смотреть на это через призму такого подхода, то для Microsoft продукт не умер, не прекратил развитие в 1998 — он продолжил развитие в виде всё новых и новых версий VBA. Просто к нему больше не прикручивали куперовский Ruby для получения побочного продукту/ответвления. А нишу этого ответвления решили закрыть дотнетом — Microsoft всегда хотела сделать свою Джаву, и вот наконец после Microsoft J++ получилась более удачная попытка.
В общем, на 85% это маркетинг, на 15% — технические сложности.Ничего хорошо (если рассматривать его как альтернативу или замену VB). Если просто рассматривать к какой-то ещё один бейсик — ради бога, больше бейсиков богу бейсиков.
он продолжил развитие в виде всё новых и новых версий VBA
Что? Vba6 вышла где то в 98, потом была встроенная в приложения Vba 7.1 с минимумом изменений. И всё.
С минимумом изменений? Они сделали 64-битную версию VBA, добавили тип данных LongLong и TDC для него. Это не минимум изменений, это очень сложная переботка, учитывая что виртуальная машина целиком и полностью была написана ассемблере и помимо неё в коде EB было очень много фрагментов, пришедших ещё с 16-битной эпохи.
Или претензия в чём? Вы не смотрите на 7.1, вы смотрите по билд-номерам библиотеки EB/VBA. Или по релизам офиса, в которых попадала VBA. Насколько таким образом VBA по дате своего последнего релиза пережила VB6 (98-й год)?
Кстати, и для VB6 последний релиз был вовсе не в 98-м году, потому что выпускались многочисленные SP к нему.
Почему VB6 все же умер для M$,в плане, не получил развития далее?
Где-то в конце 2000-х Microsoft выпускал Microsoft Small Basic. Я так понимаю что он просуществовал некоторое время параллельно с VB.NET и тихо издох за ненадобностью.
Ну нельзя же так. В те времена, когда бейсик был действительно актуален (когда был вшит в ПЗУ и домашний компьютер загружался в бейсик) он дал путь в профессию куче людей. Просто за это его можно и нужно уважать. Он собственно для этого и был предназначен, вы же в курсе, что BASIC это аббривиатура? Давайте теперь все детские конструкторы обзовем плохим словом и будем детей учить сразу автокаду и 3д-принтерам.
https://en.wikipedia.org/wiki/Dartmouth_Time-Sharing_System
Нужно смотреть на истоки. И там однозначно интерактивной была прородительница IDE, которая работала на одной системе а код для КОМПИЛЯЦИИ и выполнения отдавала другой.
Я давно живу и давно говорю, что так называемый "персональный компьютер" притормозил развитие индустрии программирования где то на четверть века. В 1985 в одном из моих проектов использовались асинхронный ввод вывод и многозадачность. А в 1995 нужно было придумывать всевозможные ухищрения над примитивной DOS
p.s. я это к тому, что BASIC родился не под dos и даже не под cp/m
p.s. я это к тому, что BASIC родился не под dos и даже не под cp/m
BASIC был создан из академического интереса, на больших ЭВМ, а применение нашел годы спустя на 8-ми битных и 16-ти битных персоналках с очень крохотной память и ограниченными аппаратными возможностями. На больших ЭВМ того времени BASIC был из разряда "не пришей рукав", он не мог конкурировать ни с FORTRAN-ом, ни с PL/I, ни с COBOL-ом ни даже с "Cи" на Мини.
BASIC использовался и как язык программирования и как операционная среда! Разработчики ПЭВМ использовали интерпретатор BASIC-а как замену операционной системы, которую, по большому счету, создать для таких ПЭВМ было невозможно из-за отсутствия внешних накопителей и малого обьема памяти. Это уже потом на 8-мибитках появятся привод гибких и жестких дисков, будет портирована CP/M и прочее DOS на её основе (или по мотивам), но в начале на этих машинках был только интерпретатор языка BASIC в различных плохосовместимых диалектах. И это был прогресс, потому как позволял использовать, пусть и убогую, ЭВМ простому Джону или Ивану у себя дома.
Очень они были большие
The DATANET-30 used magnetic-core memory with a cycle time of 6.94 μs. The word size was 18 bits and memory was available in sizes of 4K, 8K, or 16K words. The system could attach up to 128 asynchronous terminals, nominally at speeds of up to "3000 bits per second" (bit/s), but usually limited to the 300 bit/s supported by standard common-carrier facilities of the time, such as the Bell 103 modem.
Зависит от плотности кода. Если там что-то типа ЕС, у которой на все случаи математических операций отдельные команды и режимы (разбирали тут вроде недавно) — это слишком большая память, чтобы её экономить «методом Васика».
А если мы подключили 16 килослов по 16 (18 по понятной причине не поддерживаются) к 6502-му — есть вероятность, что Вася ещё может ограниченно приносить пользу. Но не так радикально, конечно, как в случае одной кильки рамы. Там или жизнь вся через васю-в-роме, или жизни в принципе нет :)
На счёт Джонов не знаю, а у Иванов в СССР было несколько моделей 8ми битных компьютеров с CP/M на касетах.
Я давно живу и давно говорю, что так называемый "персональный компьютер" притормозил развитие индустрии программирования где то на четверть века.
Асинхронный ввод/вывод у персональных компьютеров был и в первом IBM PC, а многозадачность появилась физически в 1984-м, программную же поддержку получила в конце 1980-х. То, что у вас в 1995-м был проект без всего этого, это не проблема персональных компьютеров в целом, это проблема вашего проекта в частности.
И вообще, не стоит смешивать наличие поддержки в железе и наличие поддержки в ОС. В Унихе, в частности, ввод-вывод синхронный (поэтому в ПОСИХе предусмотрели специальные расширения, поскольку без асинхронщины... тяжко временами), но это не из-за отсутствия железной поддержки на PDP-11 -- та же RSX-11 асинхронная насквозь. То же самое касается и ПК: и полноценная вытесняющая многозадачность, и асинхронный ввод-вывод технически были возможны и на оригинальном IBM PC, ну а что МС ДОС -- исключительно убогая никуда не годная система, это уже не вина железа (которое временами весьма кривое, но, тем не менее, достаточно функциональное).
по слухам то на чем собирали UNIX имело порядка 16КВ памяти, и вообще сначала это были части MULTICS min необходимые для одного пользователя, так что в swapping смысла не было, позже переписали на С и т.д., интересно что на q7 для sage swapping был (примерно 1958)
Ну, Уних, как его обычно понимают, требовал полноценной ПДП-11 с полноценным ММУ, причём настолько полноценным, что у большинства ПДПшек его не было (большинство имело упрощённый вариант, не позволяющий реализовать совсем полноценную виртуальную память: требовалось держать все 64 Кбайта задачи в памяти целиком, а не отдельными страницами, поскольку в случае прерывания из-за отсутствия страницы не было возможности выполнить "откат" содержимого регистров после автоинкремента/автодекремента; в полноценном ММУ был специальный регистр, запоминающий изменения в регистрах, что позволяло ОС сделать откат для последующего повторения команды, вызвавшей прерывание).
посмотрел воспоминания иx начальника Sam Morgan, получается на раннем этапе они использовали GE635->PDP7->PDP11/20->PDP11/45, PDP7 это 9-144KB, типа слухам 16КВ не противоречит, интересно что первые 1-2 года руководство довольно прохладно относилось, машины использовали других отделов, также интересно, что с самого начала прицел был на использование языка высокого уровня, что более-менее понятно, т.к. люди пришли из группы MULTICS, где использовали в основном диалект PL1, также знали, что MCP для B5000 написана на диалекте ALGOL
таки прочитал воспоминания Sam Morgan до конца, получается типа UNIX появился в общем благодаря случаю, приоритетная тематика Bell тогда была связана с радиолокацией, сам Morgan был специалист по рассчету волноводов, ФАР и т.п., что именно полезного делали Thompson, Ritchie, Kernighan и др. дошло до него типа задним числом, но не мешал людям работать, т.к. отдел был исследовательский, и так много чем занимались,
в этой связи спекулятивный, но интересный вопрос, что было бы с развитием программирования без UNIX?
например после выхода Bell из проекта Multics все работы по OS в своем отделе Sam Morgan мог закрыть, лишних людей у него не было, Bell Lab в это время новых сотрудников вообще не принимала
в этой связи спекулятивный, но интересный вопрос, что было бы с развитием программирования без UNIX?
Ничего. Свято место пусто не бывает, её роль заняла бы любая другая ОС.
в данном случае "свято место" это игра слов, или есть понимание, которое можете изложить?
Да ничего хитрого, например, на той же PDP-11 было довольно неплохое семейство ОС от DEC. Не было бы Unix, получили бы развитие, например, они. И это был бы вариант ничуть не хуже.
это конечно Ваше субъективное мнение
это конечно Ваше субъективное мнение
Ну как субъективное? Нет никаких оснований считать, что мы бы остались без популярной переносимой ОС с неплохой архитектурой. Спрос на это имелся, людей, которые этот спрос могли бы удовлетворить, было навалом. Всякие там RT-11/RSX-11 - это всего лишь возможные кандидаты, у них не было такого важного свойства как переносимости (у ранних Юниксов той эпохи, впрочем, тоже), но в остальном они вполне себе были достойной альтернативой. Да, собственно, мы до сих пор имеем следы их архитектурного наследия и в Windows 11.
что особо интересно, так это тот факт что микрософт уже к 80му году портировала под 8086 и потом еще под несколько тогдашних архитектур популярный тогда AT&T юникс, назвала его Xenix и несколько лет неплохо продавала, тем кто мог себе позволить отвалить за профессиональную систему штуку баксов, в первой половине 80х это был вообще самый популярный юникс на рынке. Тоесть, технический бэкграунд и понимание того как должна выглядеть операционка у микрософта был хорошо до всей эпопеи с дос-ом, якобы написанном в самолёте перед презентацией. Поэтому вообще удивительно, как им совесть позволяла эту убогость столько лет всему миру впаривать.
Поэтому вообще удивительно, как им совесть позволяла эту убогость столько лет всему миру впаривать.
А в чём убогость DOS была хоть? Это вполне себе обычная однопользовательская ОС на момент появления, и она вполне себе соответствовала своему назначению где-то до конца 1980-х. А там уже Майки и в полуось вкладывались, и в винду, и в NT.
Подобная система уместна на 8-разрядном компутере с его жутко ограниченными ресурсами, поэтому я не бурчу против, скажем, CP/M. Но даже у самого первого IBM PC оператива могла иметь объём до 256 Кбайт (а технически -- и все 640, просто в варианте 1981 года не предусматривалось использование микросхем ОЗУ по 64 Кбита, а 16-Кбитных требовалось бы слишком много), а у его следующего варианта, как и всех последующих машин перешли на микросхемы в 64 Кбита и получили до тех самых пресловутых 640 Кбайт (у PC/XT 256 Кбайт был уже минимальный объём).
Для сравнения: моя любимая RSX-11 в полноценном варианте успешно работала на машине с ОЗУ в 248 Кбайт, причём под себя жрала порядка половины этого объёма -- и при этом была многозадачной многопользовательской системой, а не однопользовательским ублюдством, как МС ДОС, которая при этом жрала вполне сравнимый объём памяти (при этом пользуясь услугами ввода-вывода из БИОС, в то время как RSX-11 все драйверы включала в себя: в ПЗУ у PDP-11 был только начальный загрузчик). В общем, функционала у МС ДОС мало, а потребностей в памяти -- много; единственное, что у неё лучше, и то лишь отчасти -- это древовидная файловая система ("отчасти" по той причине, что у неё не было никаких прав доступа к файлам, в отличие от файловой системы RSX-11). Впрочем, написать драйвер файловой системы, подобной FAT12/16/32, для RSX-11 можно без особых проблем: система легко расширялась в любую сторону (драйверы файловых систем -- это драйверы режима пользователя, поэтому они не имели жёстких ограничений по размеру, в отличие от драйверов режима ядра).
Но даже у самого первого IBM PC оператива могла иметь объём до 256 Кбайт
64К, если точнее. 256 - это уже у второго :)
Для сравнения: моя любимая RSX-11 в полноценном варианте успешно работала на машине с ОЗУ в 248 Кбайт, причём под себя жрала порядка половины этого объёма
Ну а DOS потребляла килобайт 60 в самых последних версиях, если в UMB её не прятать. И при запуске программ ещё и командный процессор из памяти выгружала. А более ранние версии DOS вообще в 30 кб укладывались, при этом уже имя поддержку жестких дисков и FAT16. Функции ПЗУ? Ну, ещё несколько килобайт, это ни о чём. Я не скажу по памяти, сколько там обработчики прерываний в оригинальной IBM PC занимают, но ПЗУ "Поиска" с поддержкой FDD и HDD, это 12К, из них 2К - это знакогенератор, плюс там же ещё начальная инициализация и POST, монитор и утилита форматирования жесткого диска. При этом ещё и код PDP-11 более компактный, чем х86. Поэтому вы сравниваете несравнимое - систему куда более легковесную и простую для персонального компьютера, с навороченной для компьютера многопользовательского. Причём с аппаратной поддержкой переключения задач.
64К, если точнее. 256 - это уже у второго
Нет, именно 256 Кбайт у первого варианта, поскольку, помимо микросхем памяти на системной плате, сразу предлагались и дополнительные платы расширения.
Ну а DOS потребляла килобайт 60 в самых последних версиях, если в UMB её не прятать. И при запуске программ ещё и командный процессор из памяти выгружала.
Эти "килобайт 60" -- как раз при выгруженном командном процессоре, и его я не считаю (в RSX-11 его аналог, MCR -- обычная привилегированная задача, а соответственно, тоже может системой загружаться/выгружаться по мере необходимости). Верхнюю память не рассматриваем, так как это эксплуатация багофичи 80286, которой у 8086/88, понятное дело, не было (а на 80286 правильней было бы делать уже защищённый режим, если бы в Интеле сидели вменяемые архитекторы и обеспечили бы совместимость -- но делать нормально, как уже 10-15 лет делали другие, им религия не позволяла что тогда, что сейчас).
Кстати говоря, RSX-11 вполне можно было урезать до килобайт 30, причём совершенно штатными средствами -- хотя она всё равно оставалась многозадачной многопользовательской (но уже без защиты памяти, поскольку такой кастрированный вариант предназначался для машин без MMU). Ну а однозадачный монитор SJ в RT-11 вообще требует... не помню, но что-то вроде 5-6 килобайт под себя, его даже на БКшку с её 16 Кбайтами ОЗУ портировали.
Так что МС ДОС -- это исключительно малофункциональное поделие, занимающее для своего функционала крайне много места в ОЗУ.
Функции ПЗУ? Ну, ещё несколько килобайт, это ни о чём.
Это вполне "о чём", когда речь идёт о системах, занимающих 50-100 килобайт памяти, поскольку функции БИОСа вполне тянут на 10-15% от общего объёма кода.
При этом ещё и код PDP-11 более компактный, чем х86.
Неверно, код для 8086/88 зачастую более компактный, чем для PDP-11, если писать на ассемблере и достаточно качественно.
Поэтому вы сравниваете несравнимое - систему куда более легковесную и простую для персонального компьютера, с навороченной для компьютера многопользовательского. Причём с аппаратной поддержкой переключения задач.
Во-первых, я сравниваю сравнимое -- ОС для компьютеров с более-менее одинаковым объёмом памяти. "Персональность" вообще ни разу роли не играет, мне на персоналках под ДОСом было крайне некомфортно из-за того, что я лишён возможности запускать несколько задач параллельно, хотя ресурсы машины это позволяют.
Во-вторых, никакой аппаратной поддержки переключения задач в PDP-11 никогда не было. Она есть в 80286 и IA-32 (80386 и последующие в защищённом 16- или 32-разрядном режиме). И, более того, такая поддержка попросту не нужна, недаром та же Винда этой возможностью не пользуется и переключает задачи чисто программно, "ручками" сохраняя и восстанавливая контекст (и поэтому в 64-разрядном режиме эту аппаратную поддержку выпилили вместе с сегментацией и рядом других вещей).
Нет, именно 256 Кбайт у первого варианта, поскольку, помимо микросхем памяти на системной плате, сразу предлагались и дополнительные платы расширения.
В то время это было физически невозможно при всём желании. Самая объемная и дорогая микросхема памяти - 4116, 16 килобит. Восемь микросхем на 16К, в плату расширения влезало четыре линейки, 64К. В IBM PC всего пять слотов расширения, из них три
Эти "килобайт 60" -- как раз при выгруженном командном процессоре
Вот чистая DOS 6.22 без всяких приблуд. Сколько вам там памяти оставит RSX-11? Так это, минуточку, самая последняя версия, вышедшая, когда память измерялась уже в мегабайтах, и уже используемая больше для поддержки винды, чем для автономной работы.
Во-первых, я сравниваю сравнимое -- ОС для компьютеров с более-менее одинаковым объёмом памяти. "Персональность" вообще ни разу роли не играет
Назначение компьютера - это его определяющая функция, а не объем памяти. Такой же объем памяти вы можете найти и у промышленного контроллера, и у сигнального процессора, но вы же не будете сравнивать их софт между собой. PDP-11, это архитектура, изначально создававшаяся под многопользовательскую работу, с поддержкой нескольких терминалов, и с узеньким каналом между ними и собственно компьютером. РС - это сугубо однопользовательская машина, в которой она сам себе терминал.
Во-вторых, никакой аппаратной поддержки переключения задач в PDP-11 никогда не было.
А разве MMU там не умел сохранять контекст регистров между переключением задач?
В то время это было физически невозможно при всём желании. Самая объемная и дорогая микросхема памяти - 4116, 16 килобит. Восемь микросхем на 16К, в плату расширения влезало четыре линейки, 64К. В IBM PC всего пять слотов расширения, из них три
Читайте техописание на IBM PC от августа 1981 года, где английским по белому написано:
Таким образом, имеем до 64 Кбайт на системной плате и по 64 Кбайта на каждой плате расширения, что даёт 256 Кбайт при трёх платах (ещё два разъёма расширения уходят на один или два видеоадаптера или видеоадаптер и ещё что-нибудь -- контроллер флопов, как правило).
И, кстати, микросхемы по 64 Кбита уже производились -- просто цена одного бита была выше, чем в 16-килобитных, поэтому для удешевления использовали последние. Но уже в варианте 1983 года перешли на 64-килобитные.
Вот чистая DOS 6.22 без всяких приблуд. Сколько вам там памяти оставит RSX-11?
Так это зависит от исходного объёма памяти. Система в полном варианте под себя и драйверы сожрёт 100-120 килобайт, остальное свободно (т.е. свободным будет порядка 120 килобайт на наиболее распространённых машинах с 248 Кбайтами ОЗУ, но почти 2 Мбайта на старших моделях с 2 Мбайтами ОЗУ). И снова повторюсь: у МС ДОС почти никаких функций нет, по большому счёту, она обеспечивает лишь работу с файлами. А RSX-11 -- многозадачная многопользовательская даже в минимальном варианте, с поддержкой асинхронного ввода-вывода, таймерных событий, обмена данными (сообщениями) между задачами и т.д. и т.п. Так что МС ДОС по набору функционала уместней сравнивать с RT-11, однозадачный монитор которой (SJ) занимал только 4 Кбайта и мог использоваться на машинах, начиная с ОЗУ в 16 Кбайт, а двухзадачный (FB) -- 8 Кбайт. Вот и сравните эффективность реализации этих систем.
Назначение компьютера - это его определяющая функция, а не объем памяти.
И IBM PC, и PDP-11 -- универсальные вычислительные машины, степень их "персональности" не играет вообще никакой роли. Более того, в линейке PDP-11/LSI-11 полно компьютеров, которые сейчас назвали бы персональными, включая самую первую модель -- PDP-11/20, появившуюся в 1969 году (или, например, наши ДВК). Ресурсы же, и, в первую очередь, объём оперативной памяти, определяют набор функций, которые способна потянуть данная машина. IBM PC тянуть могла больше, чем большинство PDPшек, а PC/AT -- чем любые PDPшки и ряд 32-разрядных VAX-11, однако они оставались крайне убогими в силу ужасающей убогости их программного обеспечения. Ещё раз повторюсь: система уровня MS DOS -- это удел 8-разрядных компьютеров, поскольку MS DOS не имеет принципиальных отличий от CP/M по своему функционалу, но её сделали системой для намного более мощных машин.
А разве MMU там не умел сохранять контекст регистров между переключением задач?
MMU делало то, что должно делать, -- отображало виртуальные адреса на физические, и ничего сверх этого. При переключении задач ОС должна была перепрограммировать регистры отображения MMU, чтобы обеспечить переход к другому адресному пространству. Регистры самого процессора всегда сохранялись-восстанавливались ручками. Плюс, MMU отсутствовало на всех LSI-11 и на изрядной части PDP-11, что не мешало гонять на них многозадачные системы при наличии достаточно большого объёма ОЗУ (32-56 Кбайт в зависимости от ОС).
Таким образом, имеем до 64 Кбайт на системной плате и по 64 Кбайта на каждой плате расширения, что даёт 256 Кбайт при трёх платах
Ну ок, но у вас там нет трех свободных разъемов :) У вас там видеокарта, контроллер флопов и контроллер портов ввода-вывода стоят. Три свободных слота, это только в конфигурации с кассетным магнитофоном. И опять же таки, DOS разрабатывалась таким образом, чтобы вы могли работать на компьютере с 64К, не покупая за штуку баксов ещё и плату расширения памяти.
снова повторюсь: у МС ДОС почти никаких функций нет, по большому счёту, она обеспечивает лишь работу с файлами.
Ну здрасьте :) Кроме собственно обвеса файловой системы - управление потоками ввода-вывода, IOCTL, поддержка оверлеев, поддержка резидентов, консольный ввод-вывод, управление кодовыми страницами, управление памятью, поддержку сетевых драйверов. Она не такая уж простая, как вам кажется. Просто у вас не было необходимости в неё погружаться.
IBM PC тянуть могла больше, чем большинство PDPшек, а PC/AT -- чем любые PDPшки и ряд 32-разрядных VAX-11
Так она и тянула реально больше. Только в других задачах. Много ли на PDP-11 было штук вроде Lotus 1-2-3, P-CAD, AutoCAD, Microsoft Word, dBase III и т.д.?
Ну ок, но у вас там нет трех свободных разъемов :) У вас там видеокарта, контроллер флопов и контроллер портов ввода-вывода стоят. Три свободных слота, это только в конфигурации с кассетным магнитофоном. И опять же таки, DOS разрабатывалась таким образом, чтобы вы могли работать на компьютере с 64К, не покупая за штуку баксов ещё и плату расширения памяти.
У оригинальной IBM PC в сумме пять разъёмов расширения, так что при необходимости впихнуть 256 Кбайт было возможно уже в первый вариант, о чём прямо говорит техописание (и показывает необходимые для этого положения переключателей).
Ну и, кроме того, брать 16-разрядный компьютер чисто чтоб дома поиграть, особого смысла тогда (в 1981-82 годах) не было -- для этого существовали очень неплохие 8-разрядные компы, которые ещё долго оставались вполне себе конкурентоспособными в этой области. 16-разрядный же, да ещё от IBM, -- это, в первую очередь, для бизнеса, где вопрос цены так остро не стоит; для домашнего применения -- это уже вторично (предусмотрели подключение к телевизору -- но с потерей качества изображения, чуть позже сделали обрубок PCjr, который не взлетел).
И да, PDPшки ж тоже начинались не с 2 Мбайт ОЗУ, а с, кажется, 16 Кбайт, а из всей периферии изначально были только телетайп и перфолента -- поэтому ДЕК и выкатила за примерно пять лет целый ворох ОСей, начиная с перфоленточной и кончая как раз RSX-11. Так что, если говорить об ОС, то для ранних IBM PC с малым объёмом памяти (например, 64 Кбайта только на системной плате) MS DOS, как мы её знаем, была бы разумным вариантом (как CP/M была нормальной на 8-разрядных компьютерах с аналогичным объёмом памяти), но вот на немного более поздних, где 256 и больше килобайт стали нормой, для эффективной работы явно требовалась более мощная и удобная система -- а её не было ещё лет 10 (по большому счёту, до появления более-менее пригодной для использования Винды 3.1, если говорить о потребительском секторе, ну а первой по-настоящему нормальной системой из мелкомягких стала лишь WinNT 4 -- а это уже 32-разрядные компы).
Ну здрасьте :) Кроме собственно обвеса файловой системы - управление потоками ввода-вывода, IOCTL, поддержка оверлеев, поддержка резидентов, консольный ввод-вывод, управление кодовыми страницами, управление памятью, поддержку сетевых драйверов. Она не такая уж простая, как вам кажется. Просто у вас не было необходимости в неё погружаться.
Управления памятью и резидентами там, по большому счёту, нет -- в силу однозадачности системы (а возможность откусить часть памяти в верхних адресах имеется и без всякой системной поддержки). Это вам не возможность создавать/уничтожать разделы памяти, загружать/выгружать задачи и совместно используемые библиотеки и т.д. и т.п., что было в RSX-11.
Насчёт поддержки оверлеев именно в МС ДОС (в самой системе) я, честно говоря, не помню, хотя мне кажется, что поддерживала их не система, а сами программы собственными силами; но вполне может быть, что за давностью лет ошибаюсь. В RSX-11 она точно была на уровне собственно ОС (и её штатного компоновщика, который и собирал оверлейные задачи под чутким руководством скрипта, описывающего оверлеи) и использовалась интенсивнейшим образом для "тяжёлых" задач; компилятор Кобола так ващще из одних оверлеев состоял :) В частности, для систем с малым объёмом ОЗУ можно было драйвер файловой системы (задача FOCACP) собрать как жутко оверлейный, но, есно, и жутко тормозной, а вот на системе, где памяти достаточно много, собрать его вообще без оверлеев. На системах с MMU и большим свободным объёмом ОЗУ (скажем, на PDP-11/70 или нашей СМ-1420, где типичным был объём физической памяти 2 Мбайта, хотя встречались и варианты с 248 Кбайтами) система умела использовать "оверлеи в памяти": обычные оверлеи грузить сразу в физическую память, а переключаться между ними по запросам задачи (по сути, по запросам кода, сформированного компоновщиком в необходимых местах задачи) с помощью регистров MMU без дополнительных обращений к диску, что, естественно, в 100500 раз быстрей.
Всё остальное, что Вы упомянули, -- это ввод-вывод, причём, в общем и целом, куда более примитивный, чем в RSX-11 (попробуй без грязных хаков запустить параллельно несколько операций ввода-вывода и продолжать при этом свою работу, отвлекаясь для обработки завершения одной операции и запуска следующей). Разве что с поддержкой сетей, наверное, в МС ДОС было лучше, но это уже следствие разницы эпох: в 1970-е, когда RSX-11 была создана и развивалась, сети только-только начинали появляться и оставались ещё чисто полем для экспериментов. Ну, ещё кодовые страницы, коих в RSX-11 не было -- но в те годы и чисто в Америке в этом нужды не было, а о других странах особенно не думали (а у нас, украв системы, сделали кучу извращённых и не совместимых друг с другом кодировок, из-за чего и пошли всякие IНЖАЛИД ДЕЖИЦЕ -- но это уже вопрос к нашим "гениям", а не к ДЕКовским системам).
overlay кода для DOS были, типа специальный linker от независимых компаний за разумную цену, плюс текстовый файл конфигурации, и работает более-менее автоматически, по памяти довольно сложные конфигурации приходилось видеть с десятками областей overlay
Нет, что оверлейные программы в МС ДОС были, я знаю -- просто мне кажется, что система это никак не поддерживала, и они реализовались полностью сторонними средствами (в отличие от RSX-11 или там OS/360, где это было на уровне штатных средств самой ОС и её штатного компоновщика).
Нет, что оверлейные программы в МС ДОС были, я знаю -- просто мне кажется, что система это никак не поддерживала, и они реализовались полностью сторонними средствами
В структуре EXE-файла в описании сегмента есть его оверлейный идентификатор, а в DOS API есть функция Load Overlay. Другое дело, что DOS никак не запрещает использовать другие оверлейные менеджеры.
У оригинальной IBM PC в сумме пять разъёмов расширения, так что при необходимости впихнуть 256 Кбайт было возможно уже в первый вариант
Ну только система будет не функциональной. Или без видео, или без дисков, или без портов ввода-вывода.
И да, PDPшки ж тоже начинались не с 2 Мбайт ОЗУ, а с, кажется, 16 Кбайт
Само собой. Но и RSX-11 у них в такой конфигурации ни в каком виде быть не могло. А вот PC DOS даже на 16К вполне себе запускалась, хотя смысла в этом особого не было.
но вот на немного более поздних, где 256 и больше килобайт стали нормой, для эффективной работы явно требовалась более мощная и удобная система
Неа, в большинстве случаев совсем наоборот. Память - самый ценный ресурс. Все эти трюки MS DOS вроде упрятывания её в верхние блоки, это всё ради экономии килобайт и килобайт памяти для прикладного софта. Вы же поймите, мир PDP-11 был совсем другим. У вас там софтины - это текстовые утилитки, часто с одним входом и выходом, обычно укладывающиеся в 64К. Они простые, зато их много. Мир PC - это одиночные, но зато крупные интерактивные и многофункциональные приложения. Им нужно как можно меньше ОС, но зато как можно больше памяти.
Там, где 256К и DOS, вы можете и писать софт в Турбо Паскале, и проектировать простые схемы в PCad, и детали в Автокаде. Там, где у вас была бы чудесная возможность переключаться между Автокадом и чем-то ещё (а чём, кстати? Не браузером же, и не плейером?), у вас бы не работал Автокад.
В мсдос своей сети не было. появилась такая поддержка только в win 3.11
Требовались отдельные внешние программные пакеты типа msnet или lantastic
есть определённая разница между стартапом с двумя разрабами выкатывающим фичи на пределе своих возможностей и способностей, и уже устоявшейся компанией с продаваемым за хорошие деньги серьёзным продуктом, пусть даже они его не сами разработали а только портировали - опыт был, масса готового кода и инфраструктура, неплохие машинки VAX/11 для сборки у них уже в компании использовались.
Аргументы, которые приводились почему Xenix не годится для PC, может быть и имели смысл в самом начале эпопеи, когда IBM сам не знал что хочет, если расчитывали продавать машинки для бизнеса с 16-64кб оперативы. Но ведь очень скоро, буквально через год-два, они вполне доросли до запросов Xenix - 256кб и жесткий диск, и с того момента не было больше никакой причины кроме чисто маркетинговой, почему бы например в поставку DOS не включить редактор vi и менеджер терминалов типа screen, что бы сразу сделало систему значительно удобнее для пользователей, и практически без затрат со стороны разработчика, потому что весь код у них уже был. Но это бы повредило имиджу дорогого продукта.
В результате, сами MS во все времена присутствовали в экосистеме юникса и были в курсе любого прогресса, однако для пользователей DOSа создали свою экосистему и старательно их от мира юникса изолировали. Ибо нефиг нищебродам делать удобно, а то элита посмотрит и дорогой продукт покупать перестанет.
почему бы например в поставку DOS не включить редактор vi и менеджер терминалов типа screen
Ответ тут лежит на поверхности. В ранних версиях DOS железо тогдашних PC редактор vi вряд ли бы осилило. Его и железо PDP-11 не осиливало уже в 1980-е. А куцый малофункциональный редактор похожей парадигмы в DOS и так был. В поздних версиях DOS появился уже нормальный обычный редактор Edit.
Что касается менеджера терминалов, у меня вообще загадка: для каких задач эта штука могла бы пригодиться пользователю компьютера, на котором работа не предполагает повседневного использования вороха консольных утилит?
В каком месте vi "значительно удобнее для пользователей"?
MS к 80 году портировала популярный AT&T UNIX ...
точнее MS купила лицензию на старый код у AT&T c условием выплаты royalty fee с каждой проданной копии, и рассчитывала вместе с SCO и др. хорошо заработать на porting и перепродаже UNIX, но AT&T их всех слегка кинула выпустив новую версию UNIX System III и позднее System V чтобы продавать напрямую, MS пыталась конкурировать выпустив Xenix System V, но решила бросить это дело и заняться OS/2 вместе с IBM, права на Xenix были переданы SCO которая фактически делала большую часть работы по porting на 286, она продолжала работы по Xenix дальше, с 1985 MS стала работать с IBM по OS/2, чем это закончилось здесь уже обсуждалось
Что интересно — в VB6 то, что скомпилировано в псевдокод (P‑Code) на современных компах работает гораздо быстрее, чем то, что скомпилировано в Native Code. Чуть ли не на порядок. По крайней мере так было на всех компах, где я тестил (Win7/8/8.1/11).
ChatGPT считает, что это потому, что P-код компактнее, а потому попадает в L1 и L2-кеши, современные процессоры оптимизированы под исполнение инструкций виртуальной машины и её предсказуемого цикла работы, сама виртуальная машина MSVBVM60.dll — хорошо оптимизирована внутри, цикл диспатча укладывается в L1/L2. В то же времчя нативный код, который порождал компилятор VB6, оптимизирован под Pentium 1/2, а не под современные процессоры, распыляет логику по разным веткам, неэффективно использует регистры процессора и т.д. В итоге нативность кода тонет в промахах кеша, пайплайна и предсказания ветвлений.
В итоге нативность кода тонет в промахах кеша, пайплайна и предсказания ветвлений.
Я не думаю, что можно в разы ухудшить работу нативного кода по сравнению с виртуальной машиной путём его какой-то там оптимизации под полтора прямолинейных конвейера первопня. И если оно всё влезло в кеш вместе с исполняющей средой, то нативно уж точно влезет. Тут больше вопрос в том, что этот код там такого делает?
ChatGPT не далёк от истины. Каждой P-code-ной инструкции соответствует кусочек машинного кода виртуальной машины, имплементирующий функциональность этой инструкции. Эти кусочки очень компактны, состоят всего из нескольких машинных инструкций, они написаны на MASM-е, то есть это даже не процедуры/функции — у них нет прологов, у них нет эпилогов, то есть нет сохранения регистров (которые соглашение о вызове предписывает оставлять нетронутыми), нет восстановления регистров в конце, нет резрвирования места в стеке под локальные переменные. В них есть только сама суть, так как они написаны на ассемблере. Поэтому они очень компактны.
И поскольку они очень компактны (а также из-за того, что для реально одинаковых поддействий из таких кусочков всё-таки вызываются классические процеды), реализация самых «популярных» P-кодных инструкций очень быстро попадает в кеш процессора. P-кодый код, если там выполняюся одни и те же процедуры VB-проекта, или много циклов, попадают в кеш данных процессора.
Таким образом, для процессора выполнение большей части VB-кода превращается в исполнение уже очень хорошо знакомых (с точки зрения кеша) макро-блоков.
P-кодый код, если там выполняюся одни и те же процедуры VB-проекта, или много циклов, попадают в кеш данных процессора.
Вопрос же не в этом. Вопрос в другом - чем это с точки зрения кеша процессора может настолько отличаться от выполнения этого же алгоритма, но уже сразу в нативных инструкциях? Особенно с учётом того, что современный кеш и так без проблем затянет целиком все попавшиеся ему исполняемые страницы приложения.
чем это с точки зрения кеша процессора может настолько отличаться от выполнения этого же алгоритма, но уже сразу в нативных инструкциях?
Просто тем, что тот же самый алгоритм представляется малым количеством много раз повторяемых макро-блоков машинного кода.
Без всякой P-кодной виртуальной машины можно представить себе такую же ситуацию на примере программы на Си или C++: представьте, что вы задали такие ключики компиляции, что приказали заинлайнить абсолютно всё. Инлайнятся абсолютно все функции, маленькие и большие, а также, допустим, вы как-то заставили компилятор разворачивать все циклы, где число итераций известно в момент компиляции. И плюс ещё вы отключили COMDAT Folding у линкера. Каким будет результат?
Очень запросто этот трюк с инлайнингом может замедлить выполнение нативного исполняемого файла, потому что:
Он раздувает размер машинного кода, и это сказывается на увеличении количества страниц, и если у вас включен включен и штатным образом работает механизм подкачки, то просто может оказаться, что время от время выполнение будет переходить на страницу, котороая нет в физической памяти, которая выгружена, и ОС придётся её подгружать с диска, а это медленно. Естественно, это происходит только при первом обращении к странице, но если в системе много одновременно работаюших приложений, большой объём суммарно выделенных страниц памяти, большой объём файла подкачки (или файлов подкачки — их может быть несколько), но по сравнению с этим малый объём физической памяти, то конкуренция за страницы ФП может быть большой и та же страница в скором времени опять может быть выгружена и всё повторится при следующем обращении. И
Он просто раздувает код и заставляет появляться там повторяющимся паттернам машинных инструкций, которые процессор вынужден декодировать каждый раз как в первый раз, хотя он мог бы взять это в uop-кеше. Когда я говорю «каждый раз как в первый раз», я не имею в виду повторные вызовы того же самого кода, я имею в виду что если у вас развернулся цикл из 1024 итераций в «китайский код», то тело цикла будет декодироваться 1024 раза. Опять же, когда дело дойдёт того следующего раз, когда этот код должен будет выполниться, не факт, что он к этому моменту сохранится в кешах процессора. В системе ведь может быть ещё куча других процессов, и все конкурируют за кеши.
Вот в статье я приводил в качестве примера функции GetMinAndMax и Fact, показывая, что при компиляции в машинный код их код достаточно рационально компактен и ничем не уступает аналогиному сишному коду. Естественно, эти примеры взяты не с потолка: когда я пишу код (хоть на VB, но на C и C++), у меня в голове уже есть представление, во что это скомпилируется или примерно может скомпилироваться. Точно так же, как я могу выбрать удачный пример, я могу выбрать и анти-пример:
Public Function Heavyproc(ByVal FirstName, ByVal LastName, _
ByVal Age, ByVal Occupation, _
ByVal Address, ByVal SSN)
End FunctionАбсолютно пустая функция, ничего не делающая, но аргументы типов — Variant и они передаются ByVal, а под капотом Variant это 16-байтная структура, и всё усугубляется правилами владения и управления ресурсами, на которые есть «ссылки» изнутри VARIANT-структур.
Поэтому эта пустая абсолютно ничего не делающая функция компилируется вот в такой машинный код:
Heavyproc . 55 PUSH EBP
. 8BEC MOV EBP, ESP
. 83EC 08 SUB ESP, 8
. 68 E6104000 PUSH __vbaExceptHandler
. 64:A1 00000000 MOV EAX, DWORD PTR FS:[0]
. 50 PUSH EAX
. 64:8925 00000000 MOV DWORD PTR FS:[0], ESP
. 83EC 64 SUB ESP, 64
. 53 PUSH EBX
. 56 PUSH ESI
. 57 PUSH EDI
. 8965 F8 MOV DWORD PTR SS:[EBP-8], ESP
. C745 FC C0104000 MOV DWORD PTR SS:[EBP-4], 004010C0
. 8B35 70104000 MOV ESI, DWORD PTR DS:[<&MSVBVM60.__vbaVarDup>]
. 33C0 XOR EAX, EAX
. 8D55 0C LEA EDX, DWORD PTR SS:[EBP+C]
. 8D4D D0 LEA ECX, DWORD PTR SS:[EBP-30]
. 8945 E0 MOV DWORD PTR SS:[EBP-20], EAX
. 8945 D0 MOV DWORD PTR SS:[EBP-30], EAX
. 8945 C0 MOV DWORD PTR SS:[EBP-40], EAX
. 8945 B0 MOV DWORD PTR SS:[EBP-50], EAX
. 8945 A0 MOV DWORD PTR SS:[EBP-60], EAX
. 8945 90 MOV DWORD PTR SS:[EBP-70], EAX
. FFD6 CALL ESI
. 8D55 1C LEA EDX, DWORD PTR SS:[EBP+1C]
. 8D4D A0 LEA ECX, DWORD PTR SS:[EBP-60]
. FFD6 CALL ESI
. 8D55 2C LEA EDX, DWORD PTR SS:[EBP+2C]
. 8D4D E0 LEA ECX, DWORD PTR SS:[EBP-20]
. FFD6 CALL ESI
. 8D55 3C LEA EDX, DWORD PTR SS:[EBP+3C]
. 8D4D C0 LEA ECX, DWORD PTR SS:[EBP-40]
. FFD6 CALL ESI
. 8D55 4C LEA EDX, DWORD PTR SS:[EBP+4C]
. 8D4D 90 LEA ECX, DWORD PTR SS:[EBP-70]
. FFD6 CALL ESI
. 68 7C174000 PUSH 0040177C
. EB 0A JMP SHORT 0040175C
. 8D4D B0 LEA ECX, DWORD PTR SS:[EBP-50]
. FF15 10104000 CALL DWORD PTR DS:[<&MSVBVM60.__vbaFreeVar>]
. C3 RETN
> 8B35 10104000 MOV ESI, DWORD PTR DS:[<&MSVBVM60.__vbaFreeVar>]
. 8D4D E0 LEA ECX, DWORD PTR SS:[EBP-20]
. FFD6 CALL ESI
. 8D4D D0 LEA ECX, DWORD PTR SS:[EBP-30]
. FFD6 CALL ESI
. 8D4D C0 LEA ECX, DWORD PTR SS:[EBP-40]
. FFD6 CALL ESI
. 8D4D A0 LEA ECX, DWORD PTR SS:[EBP-60]
. FFD6 CALL ESI
. 8D4D 90 LEA ECX, DWORD PTR SS:[EBP-70]
. FFD6 CALL ESI
. C3 RETN
. 8B45 08 MOV EAX, DWORD PTR SS:[EBP+8]
. 8B55 B0 MOV EDX, DWORD PTR SS:[EBP-50]
. 8BC8 MOV ECX, EAX
. 8911 MOV DWORD PTR DS:[ECX], EDX
. 8B55 B4 MOV EDX, DWORD PTR SS:[EBP-4C]
. 8951 04 MOV DWORD PTR DS:[ECX+4], EDX
. 8B55 B8 MOV EDX, DWORD PTR SS:[EBP-48]
. 8951 08 MOV DWORD PTR DS:[ECX+8], EDX
. 8B55 BC MOV EDX, DWORD PTR SS:[EBP-44]
. 5F POP EDI
. 8951 0C MOV DWORD PTR DS:[ECX+C], EDX
. 8B4D F0 MOV ECX, DWORD PTR SS:[EBP-10]
. 5E POP ESI
. 64:890D 00000000 MOV DWORD PTR FS:[0], ECX
. 5B POP EBX
. 8BE5 MOV ESP, EBP
. 5D POP EBP
. C2 5400 RETN 54
Вот тебе и абсолютно пустая функция!
Если присмотреться и разобраться, то здесь просто есть огромный пролог и сразу же огромный эпилог функции.
Пролог делает:
Установка EBP для нового фрейма.
Добавляет новый SEH-хендлер в цепочку.
Резервирует место под семь локальных переменных типа VARIANT — шесть под копии аргументов и одну под переменную, хранящую возвращаемое значение функции до непосредственно самого возврата из функции (это одноимённая переменная Heavyproc с именем таким же, как у своей родительской функции).
Зануляет первое поле .vt у каждой структуры, чтобы структура считалась инициализированной (и при этом пустой).
Шесть раз вызывает __vbaVarDup для копирования переданного аргумента в локальную переменную-копию.
Эпилог делает обратное:
Шесть раз вызывает __vbaFreeVar для зачистки VARIANT-структуры с освобождением ресурсов, которыми она могла владеть.
Вручную перемещает начинку Heavyproc в предоставляемый вызывающей стороной приёмник возвращаемого значения.
Восстанавливает неизменяемые регистры (EDI, ESI, EBX), убирает SEH-фрейм.
Во всём этом машинном коде нет никакой бизнес-логики приложения (функция-то пустая у нас в исходнике, только само объявление), но есть масса инструкция для выполнения всмогательных вещей.
Компилятор догадался соптимизироваь вызов __vbaVarDup, поместив адрес вызываемой функции в ESI и делая потом только call esi, но аргументы для вызова (а __vbaVarDup использует fastcall) вычисляются (с помощью LEA) каждый раз в индивидуальном порядке.
И этого всего лишь 6 аргументов (а могло бы быть 26) на фоне абсолютно пустой функции.
Если же скомпилировать тот же VB-код в P-code, то функция Heavyproc будет состоять всего лишь из 7 P-кодных инструкций:
FDupVar ...
FDupVar ...
FDupVar ...
FDupVar ...
FDupVar ...
FDupVar ...
ExitProcCb ...Здесь и проявляется разница: когда виртуальная машина 6-раз выполняет VM-ную инструкцию FDupVar, она шесть раз выполнят один и тот же макро-блок машинного кода, который уже давно сидит как просто в L1I-кеше (и эти инструкции не надо дёргать из памяти), так и в uop-кеше (и процессору даже не надо заново их декодировать). И поскольку это довольно часто используепмые P-кодные инструкции, вызываемые практически из любой процедуры VB-кода, то их машинные имлементации никогда не вылезают из кешей, и страницы памяти, на которые приходятся эти имплементации в машинном коде, тоже вряд ли выкидываются из working set'а.
Сама имплементация P-кодной инструкции FDupVar в виртуальной машине выглядит вот так:
По сути тут тот же самый вызов __vbaVarDup, который шесть раз делался из native code в примере выше. Только там это было 6 раз разных, подряд идущих вызовов, а здесь это один и тот же вызов, повторяемый шесть раз как бы в цикле.
Цикл образуется последней инструкцией (JMP, подсвеченный жёлтеньким). Во это вот mov al, [esi+4] и jmp [tblByteDisp + eax*4] это фетч новой P-код инструкции и переход на её хендлер. Когда этот кусочек машинного кода закончит обработку первой P-кодной инструкции FDupVar, он дойдёт до конца и вот этот жёлтый JMP перенесёт нас обратно на lblEX_FDupVar — и так 6 итераций в общей сложности.
И да, у инструкции FDupVar два операнда размером WORD (откуда и куда копировать Variant-значени в виде смещений относительно базы текущего стекового фрейма) и поэтому в хендлере этой инструкции (т.е. в этом кусочке машинного кода, что на картинке выше) есть два обращения к памяти (а в native коде их как бы нет, те же самые смещения вшиты в операнды LEA-инструкций). Однако, по всей видимости, эти обращения обходятся супер-дёшево, потому что тут операнды идут вплотную к опкодам FDupVar-инструкции, при «фетчинге» P-кода сразу вся кеш-линия попадает в кеш данных.
Просто тем, что тот же самый алгоритм представляется малым количеством много раз повторяемых макро-блоков машинного кода.
Если бы это могло эффективно работать подобным образом, чистые виртуальные машины, которых навалом, работали бы быстрее, чем нативный код, и им не понадобились бы такие костыли, увеличивающие производительность, как JIT-компиляция.
А это и не работает эффективно: это очень сильно зависит от кода, от того, что там делается и от того, как он написан — какой-то код будет быстрее при компиляции в native code, какой-то в P-код, плюс ещё от системы, на которой он выполняется и на которой происходит замер. В общем, русская рулетка и вопрос удачи.
Но спорить с тем, что тысячу раз выполненный вызов одной и той же native code процедуры быстрее, чем огромный native code, состоящий из тысячу раз продублированной начинки этой процедуры, тоже вряд ли имеет смысл.
Но спорить с тем, что тысячу раз выполненный вызов одной и той же native code процедуры быстрее, чем огромный native code, состоящий из тысячу раз продублированной начинки этой процедуры, тоже вряд ли имеет смысл.
А вот абсолютно не факт, кстати. Это имело смысл на процессорах этак до середины 1990-х. А уже где-то с Pentium Pro процессор на таком линейном коде с заинлайненными функциями прекрасно префетчил строки с последующими операциями в кэш из ОЗУ, пока выполняется код из текущей строки кеша. Поэтому ситуация с промахом кеша L1 на линейном коде сейчас - этот нонсенс. Это наоборот, может случиться только с какими-то зубодробительными переходами, которые не осилил блок предсказания ветвлений.
Зачем здесь нужен твой ответ, если есть ЧатГПТ?
Тем более, как и обычно у ИИ, это наполовину чушь.
Отдельно хочется сказать, что от такой локализации интерфейса VB кровь из глаз идёт.
Особенно мне нравится вкладка «Делать»...
Это ностальгическая кровь
,,, вкладка "Делать"
Вы можете предложить лучшее?
вполне понимаю, но как-то не видно вариантов
Конечно могу: самое лучшее предложение, это ничего вообще не переводить, потому что программист, не знающий английского языка на таком базовом уровне — это нонсенс.
Но если совсем невмоготу, можно было перевести как «Сборка». А так, очевидно, перевод на картинке вообще был сделан тупо засовыванием строк в ПРОМТ без понимания им контекста, в котором употребляются фразы.
Если бы спорщики дали себе труд переформулировать утверждения типа "Бейсик - интерпретируемый язык" в "Для бейсика не существует компиляторов в код с нативными инструкциями или с инструкциями какой-то виртуальной машины", то никакого спора бы не получилось. Утверждения о несуществовании разумными людьми обычно даются очень осторожно, если они разумные :).
то никакого спора бы не получилось.
Почему не получилось бы?
Бейсик — понятие размытое. У него куча диалектов и разных реализаций. Поэтому нужно говорить о конкретном диалекте и конкретном продукте. Я не говорю про все Бейсики на свете, особенно про совсем допотопные «нечто» из 60-х годов, где даже блочных IF не было и их приходилось эмулировать с помощью GOTO (убеждён, что Дейкстра именно по этой причине наезжал на Бейсик).
Но меня всегда задевают наезды на два диалекта: Visual Basic (особенно сильно) и QuickBasic (в меньшей степени, но тоже).
Для этих двух диалектов выражение «не существует компиляторов в код с нативными инструкциями» — не верны, потому что и QuickBasic-овский компилятор компилирует в нативный код для x86 (для него это вообще единственный режим), и Visual Basic тоже это делает (для него это основной режим, режим по умолчанию, но есть альтернативный режим с генерацией в код собственной виртуальной машины).
Тем не менее, даже после того, как продемонстирован код на QB/VB и непосредственно машинный код, в который его превратил соответсвующий компилятор, находятся люди, которые пишут «вы всё врёти, там виртуальный машина и вообще построчная интерпретация». Я не понимаю, что с этими людьми — наверное тяжело разрушить в голову догму, с которой жил очень долго.
Кто угодно может пнуть мёртвого льва