Как стать автором
Обновить

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

Глядя на размеры области АЛУ и регистров нельзя не задуматься о том, что для тього, чтобы сделать этот процессор 32-разрядным потребовалость бы увеличить площадь кристалла всего на 15..20%. И тогда история архитектуры 8086 была бы другой, без ограничения в 640кБайт памяти, и многого другого.
Вы ошибаетесь. Даже у 8086 не было шансов без его варианта 8088 с 8 битной шиной, для удешевления. IBM выбрал 8088 за дешевизну дизайна 8 битной платы.
Так что если бы не 8088, то скорее выбрали бы для IBM-ПК 16 битную Моторолу 68000.
Ничто не мешало сделать и вариант 32-разрядного процессора с 8-битной шиной памяти, и с 16-битной. Преимущество 8088 — в использовании более дешевой уже массово выпускаемой на тот момент 8-битной периферии. А Motorolla 68000 — это как раз 32-разрядный процессор с 16-битной внешней шиной. Преимущество 8086 перед 68000 — обратную совместимостб с 8080 (с использованием транслятора машинного кода) — можно было сохранить и в 32-разрядной версии.
32 битные процессоры проигрывают 8 и 16 битным по плотности кода.
Почитайте дальше комментарии по поводу стоимости памяти. Первые IBM PC
стоили около 1000 юсд (около 4000 сегодня) что было на грани возможности среднего класса.
Так что у IBM были веские причины выбрать именно 8088. Или это сделала бы другая компания и мы знали бы персоналки под другим именем. Успех пришел к IBM именно в результате этого выбора, ну и плюс открытая архитектура IBM-PC.
32 битные процессоры проигрывают 8 и 16 битным по плотности кода
Некоторые 32-битные процессоры проигрывают, за счёт хранения в коде 32-битных адресов. Но система команд 8086 очень гибкая в плане разрядности констант, думаю, и в этом варианте размер кода сущестенно не увеличился бы.
Насчёт памяти — 32-разрядность изначально была нужна не столько для увеличения размера адресуемой памяти, сколько для устранения ограничений, вызванных её разбивкой на сегменты с максимальным объёмом 64кБайта. Основная причина успеха IBM-PC — открытая архитектура.
Зато из истории можно извлекать уроки — костыли не стоит применять без крайней необходимости даже во временных решениях, потому что нет ничего более постоянного, чем временное.
точно, я не нахожу сейчас такой фразы, но в 90е была популярной —
винтел это 32 разрядный патч на 16 разрядную графическую среду для 8 битной операционной системы, написанной для 4х разрядного калькулятора.
расшифровка 32 — Win95, 16 — Ядро гуев в то время, 8 — CP\M, предок MSDOS и прочих, 4х — 4004,
возможное дополнение с расшифровкой — 64 разрядное расширение (2003 и более поздние варианты)
вот такой собор, собранный из невозможного количества костылей и прочих кривостей.
последней из громких кривостей, это когда интел не смог нормально реализовать AMD64 код и под него изменили данное расширение, ибо он слишком большой чтобы лопнуть. поздние процессоры и у амд трактуют код как интел. =)
всё для совместимости…
НЛО прилетело и опубликовало эту надпись здесь
И ведь плюсует это кто-то.

У Windows 95 было полностью 32-разрядное ядро, 16-битный код использовался только в специфических случаях и на небольших участках
Вот только чушь не надо пороть? Ей больно. То, что MS-DOS код в Windows 95 почти не использовался — это правда. Но архитектурно Windows 95 была развитием Window 3.1. И весь GUI там был 16-битный и куча ограничений — оттуда же.

Ни о каком 32-битном ядре никто никогда не заикался, это даже не смешно.

это скорее не про Windows 95, а про Win32s.
Архитектурно — там разницы почти нет. Да, в Win32s были проблемы с многопоточностью, а в Windows 95 их починили… но ровно по модулю того, что вы эту чудесную многопоточность имеете пока не общаетесь с GUI. Как только вам нужна графика… всё, переход в 16-битный режим, кооперативная многозадачность и все вот эти вот прелести…
И весь GUI там был 16-битный
Как только вам нужна графика… всё, переход в 16-битный режим, кооперативная многозадачность

Можно пруфы?
Там вообще-то ссылка на Wikipedia была.

Но если в Wikipedia вы не верите, то вам вам ссылка на Раймонда. Он, как человек, сотворивший знаменитый Blue Screen of Death наверное ещё кое-что про Windows 95 помнит…

Но вообще забавно: тот факт, что Windows 95 — это, в сущности, 16-битная Windows 4.0 к которой «сбоку прикручена» 32-битная подсистема настолько «всем известен», настолько «незыблем», что… ни в каких книгах он даже не упоминается. Ну ведь действительно: не будет же кто-то, в здравом уме и твёрдой памяти, писать про то, что небо — так-то, в принципе, голубое — в книжке по астрономии?

Ещё найти главу, где-нибудь посредине книги, объясняющую этот факт — вы сможете, но само упоминание такой очевидности отдельно… нелепица ведь полная!
Там вообще-то ссылка на Wikipedia была.

И по ссылке на Wikipedia — ни одного упоминания «16-битных GUI и графики». Потому я и спросил.

Но если в Wikipedia вы не верите, то вам вам ссылка на Раймонда.

Там он пишет про прототип, существовавший за несколько лет до выхода Windows 95. В другом месте он пишет, что когда проект уже назывался «Windows 95», он состоял из беспорядочной мешанины 16-битного и 32-битного кода.
В другом месте он пишет, что когда проект уже назывался «Windows 95», он состоял из беспорядочной мешанины 16-битного и 32-битного кода.
Вот только там ничего про GUI.

Ну что за детский сад, честное слово. Всем известна история про то, что Pentium Pro был непригоден для использования с Windows 95, потому что он «тормозил на 16-битном коде» (на самом деле нет)… а откуда там взялось столько 16-битного кода, что образовались томоза?

Вот как раз в GDI они и сидели. А байки про тормоза с 16-битным кодом… это городская легенда. Тормоза случались при активном использовании кода, написанного руками с ah/ch/dh/bh. Ибо разработчики Pentium Pro не предполагали, что их будут использовать вперемешку с al/cl/dl/bl… компиляторы это и в 16-битном мире не делали, а вот программисты…

Вот тут чётко и недвусмысленно об этом написано: Nearly all of GDI was written in assembly language in versions of Windows up to and including the Windows 95 family.

А вот тут — про трюки, которые из-за этого приходилось применять.

Да, в Windows 95 был 32-битный драйвер работы с диском (только он ещё в Windows 3.11 был 32-битным), да, там было много разного другого 32-битного кода… но GDI — оставался 16-битным до конца. В USER было некоторое количество 32-битных байпассов, но достаточно было загрузить хотя бы одну 16-битную программу и усё: лафа кончалась.

В общем пресловутый «32 разрядный патч на 16 разрядную графическую среду далее по тексту» — это очень ёмкое и точное описание того, что там творилось.
Вот тут чётко и недвусмысленно об этом написано: Nearly all of GDI was written in assembly language in versions of Windows up to and including the Windows 95 family.

«Написано на ассемблере» не означает «было 16-битным». Чуть выше процитированного вами куска он пишет, что в GDI esp использовался для арифметики, потому что обычных 32-битных регистров не хватило.
Господи, куда я попал. Только не говорите мне, что вы не в курсе того, что в 16-битном коде в x86 можно использовать 32-битные регистры и того, что для Turbo Pascal 7 были патчи, которые их в чистом MS-DOS использовали для ускорения вычислений?

Ну так скачайте, убедитесь, блин. Файлик называется 386PATCH.ZIP.
Господи, куда я попал.

В компанию людей, которые чуть лучше вас знают архитектуру Windows. Не стесняйтесь, не надо ;)
что в 16-битном коде в x86 можно использовать 32-битные регистры

Как вам сказать помягче. Фраза «в 16-битном коде использовать 32-битные регистры» — это примерно как «употреблять водку, но не алкоголь». Если в коде используются 32-битные регистры, он уже 32-битный. Даже если в нём используются ещё и 16-битные.
Если в коде используются 32-битные регистры, он уже 32-битный. Даже если в нём используются ещё и 16-битные.
Всё понял. MS DOS 1.0 — это у нас, нонче, 32-битная OS. Ну там же можно употребять 32-битные регистры.

И GW-BASIC — тоже 32-битный язык. Ведь через CALL вы можете в программу 32-битные вычисления вставить…

Знаете — с такими подходами что-либо обсуждать бессмысленно. Особенно с учётом того, что вы даже элементарных вещей про устройство Windows не знаете.

С таким пафосом пороть чушь… это, знаете ли, не каждому дано.
Всё понял.

Да ничего вы не поняли. У вас часть мозга, отвечающая за это самое «поняли», давно заржавела, вы живёте только теми понятиями, которые заложили в себя тогда, когда ещё могли воспринимать информацию. Без обид, но это так. Сейчас же вы хоть и создаёте видимость человека, который обрабатывает информацию, все равно это только имитация. Факты, которые подходят под ваши догмы, вы отмечаете, которые не подходят, или игнорируете, или перекручиваете с ног на голову. И при этом вы уверены, что вы правы, а остальные просто чего-то там не знают, не понимают. И знаете, самое неприятное для вас, что дальше будет только хуже.
И GW-BASIC — тоже 32-битный язык. Ведь через CALL вы можете в программу 32-битные вычисления вставить…

Да, вы можете скомпоновать 32-битный код с 16-битной программой, и да, вы можете его запустить в MS DOS 1.0. Да, при этом DOS останется 16-битной, а 32-битный код останется 32-битным кодом, который скомпонован с 16-битным. Он не превратится в 16-битный только от того, что вы его вызываете из старой 16-битной ОС.
Сейчас же вы хоть и создаёте видимость человека, который обрабатывает информацию, все равно это только имитация. Факты, которые подходят под ваши догмы, вы отмечаете, которые не подходят, или игнорируете, или перекручиваете с ног на голову. И при этом вы уверены, что вы правы, а остальные просто чего-то там не знают, не понимают. И знаете, самое неприятное для вас, что дальше будет только хуже.
Это уже вас в философию повело. Да, я знаю — умение рассуждать логически и нежеление одновременно признавать два противоречих друг друг факта за истину — сегодня не в моде. закон исключённого третьего эффективным эффектам вроде вас — не нужен.

Но я вполне нормально живу в мире, где действует логика, и колебаться вместе с линией партии мне как-то без надобности.

Если для вас любой код, куда 0x66 вписали, внезапно становится 32-битным — то у вас и MS-DOS будет 32-битной (там же HIMEM есть и EMM386!) и все версии Windows, начиная с Windows 386… вот только смысла в такой классификации — нуль.

Для меня, извините, код — 32х битный, когда он работает в 32-битном режиме процессора и 64-битный — когда в 64-битном.

Он не превратится в 16-битный только от того, что вы его вызываете из старой 16-битной ОС.
Нет, конечно. Он превратится в 16-битный, потому что он, всё равно, продолжает использоваться в 16-битном режиме процессора. И Unreal mode-код — он тоже 16-битный. Именно потому что 32-битный адрес данных вы там использовать можете, а 32-битный адрес кода — нет.

P.S. Вот интересно — куда вы запишите x32 код? Он у вас будет 32-битным, если программа тип long не использует и 64-битным, если использует? Вам не кажется что это… немножко бред? Или не кажется? Нет, наверное если по-настоящему овладеть двоемыслием, как вы, то проблем не будет. Но… зачем?
Для меня, извините, код — 32х битный, когда он работает в 32-битном режиме процессора

Вы знаете, я просто восхищён вашей глубиной знаний архитектуры х86. Глубиной в том смысле, что дно недалеко. И объективно говоря, нет ничего в этом плохого, ну не знает человек технические подробности работы процессора, ну и фиг с ним. Но проблема в том, что вы же уверены, что знаете, и воинствуете с этим, раздавая налево и направо «умные» ремарки, грубости и так далее.
А попробуйте-ка для начала найти, где у процессора включается этот некий 32-битный режим, и чем он отличается от 16-битного :)
А попробуйте-ка для начала найти, где у процессора включается этот некий 32-битный режим, и чем он отличается от 16-битного :)
Зачем искать-то? Это во всех книжках написано — в скрытой части селекторнах регистров. У 80286 и 80386 есть даже инструкции, позволяющие туда посмотреть.
Зачем искать-то? Это во всех книжках написано — в скрытой части селекторнах регистров

А вы всё-таки поищите, попробуйте. Я не просто так спросил.
MS DOS 1.0 — это у нас, нонче, 32-битная OS.

Это, конечно, мелочи, но MS-DOS 1.0 не существовала.
Вот тут чётко и недвусмысленно об этом написано: Nearly all of GDI was written in assembly language in versions of Windows up to and including the Windows 95 family.

Ну да, ну да, цитата оттуда же:
In Windows 95, the code generator got crazy and used the esp register as a general-purpose register.

Конечно же речь про 16-битный код, да ;)
Ну да, ну да, цитата оттуда же:
In Windows 95, the code generator got crazy and used the esp register as a general-purpose register.

Конечно же речь про 16-битный код, да;)
Несомненно, очевидно и безвариантно. Просто потому что если вы это сделаете в 32-битном коде, то… это добром не кончится. А 16-битном коде… нормально.

P.S. Интересно, что пассаж про esp вы заметили, а тот факт, что the code generator took advantage of 32-bit registersIn Windows 3.0 — нет. Хотя он ровно в предыдущем абсзаце. У вас уже Windows 3.0 стала 32-битной? И Turbo Pascal тоже? Вы это всерьёз?

P.P.S. Кстати только что обратил внимание: вам цитату ещё и снизу пришлось подрезать, что сову-то на глобус натянуть. Uh oh, but this means that you can’t use the esp register to access your local variables. No problem! We’ll run the code on a custom stack, too, so that our local variables are at fixed offsets relative to the stack selector register. Напрягите головушку… посильнее… где у нас stack selector register используется? В 32-битном коде? Или, всё-таки, в 16-битном? Даю подсказку: в Win32 вообще нет функций, которые позволяли бы вам такой селектор, штатным образом, создать. А вот в Win16 — без проблем: любая функция аллокации — ваш друг.
У вас уже Windows 3.0 стала 32-битной?

Windows 3.x содержит некоторое количество 32-битного кода, что вас смущает? Я, впрочем, не особо верю в то, что там речь шла именно про Windows 3.0, а не 3.1. Возможно, автор за давностью лет также забыл. Ну просто по той нехитрой причине, что 386 Enhanced Mode в 3.0 не было, и неожиданно было бы встретить код, работающий только на 386+ процах в ОС, верхними требованиями которой был 286-й.
Напрягите головушку… посильнее… где у нас stack selector register используется? В 32-битном коде?

Эм… забавный вопрос. Правда. Но боюсь, вы с вашими закостенелыми и непонятно откуда придуманными догмами просто не поверите.
Ну просто по той нехитрой причине, что 386 Enhanced Mode в 3.0 не было, и неожиданно было бы встретить код, работающий только на 386+ процах в ОС, верхними требованиями которой был 286-й.
И вы после этого будете рассказывать сказки, что вы что-то там знаете про устройство Windows?

Вот тут вы можете не только посмотреть на скриншот:
Ни и скачать саму Windows 3.0. А вот тут можете почитать как запускать её в 386 Enhanced Mode в Microsoft Virtual PC.

И прекратите принимать «вещества». Они мозг разжижают, знаете ли.

Но боюсь, вы с вашими закостенелыми и непонятно откуда придуманными догмами просто не поверите.
Человеку, который нагло и откровенно врёт… когда не передёргивает факты? Не поверю, конечно.

Потому что я, как видим, чуть-чуть лучше вашего знаю — что, когда и как в Windows появилось.

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

P.S. И да, я в курсе, что в 32-битном режиме селекторы сегментов существуют. Как и в курсе того, что Windows95 их для стека не использует. Потому что в ней все Windows-программы используют одну-единственную LDT, доступных селекторов мало и заводить на каждый процесс ещё один чисто для нужд Bit­Blt — никто не будет. А вот уже в 16-битном коде — это не нужно. Потому что кооперативная многозадачность и нужен всего один стек для библиотеки, а один селектор — это немного.
И вы после этого будете рассказывать сказки, что вы что-то там знаете про устройство Windows?

Ок, в этом моменте я ошибся, в Windows 3.0 тоже есть где выполнять 32-битный код. Это как-то отменяет остальные мои аргументы? Вы бы лучше не это, а свою бредятину про отсутствие селектора стека в 32-битном коде прокомментировали :)
UPD. Спасибо, что прокомментировали.
И да, я в курсе, что в 32-битном режиме селекторы сегментов существуют.

Только не надо лгать. Вы «в курсе» стали только после того, как прочли мой комментарий и полезли гуглить. У вас даже просто признаться «я был неправ» кишка тонка.
Вы бы лучше не это, а свою бредятину про отсутствие селектора стека в 32-битном коде прокомментировали :)
Бредятина — это у вас.

В 32-битном коде в Windows 95 селекторы не используются. Ровно потому, что это 32 разрядный патч на 16 разрядную графическую среду, все селекторы в одной LDT и попытка использовать их там «добром не кончится».

То что это, в принципе, в других операционках, возможно — я в курсе. В Windows 95 — нет.
Бредятина — это у вас.

Вы знаете, у меня для вас хреновые новости.
1. Бредятина — таки у вас
2. В Windows 95 одна LDT для 16-битной подсистемы и отдельные LDT на каждый 32-битный процесс.
3. Хоть одна, хоть много LDT, это не играет роли при использовании селектора стека. И что значит «добром не кончится»? А чем кончится?
То что это, в принципе, в других операционках, возможно — я в курсе. В Windows 95 — нет.

Погуглите что-то другое. Вы себе плохую статью нагуглили.
В Windows 95 одна LDT для 16-битной подсистемы и отдельные LDT на каждый 32-битный процесс.
Да, тут уже я ошибся.

Хоть одна, хоть много LDT, это не играет роли при использовании селектора стека. И что значит «добром не кончится»? А чем кончится?
Неработающим SEH и невозможностью обработать ошибку доступа к памяти.

Погуглите что-то другое. Вы себе плохую статью нагуглили.
Не знаю уж какую статью вы там нашли, но ни одной, объясняющей как подружить кастомный селектор стека и SEH — мне найти не удалось.

В конечном итоге там где нам было это нужно — мы выкрутились через «соседний» процесс, который следит за основным и обрабатывает все эти ошибки не допуская их до SEH.

Но обычные процессы в Windows 95 запущены не под дебаггером, а использовать BitBlt они-таки могут…
Неработающим SEH

Мы же про BitBlt говорим, какой там SEH вообще может быть?

Да, тут уже я ошибся.

Беру свои слова обратно, вы не совсем безнадёжны ;)
Неработающим SEH
Мы же про BitBlt говорим, какой там SEH вообще может быть?
Простой такой. Для которого GetExceptionCode вернёт EXCEPTION_ACCESS_VIOLATION.
Вы же сами приводили статьи, что оно на ассемблере писано. Там нет обработки исключений.
Чэнь же сам объясняет в посте, на который вы сослались: «Note that normal Win32 code can’t get away with this trick because the stack pointer must remain valid for stack unwinding purposes. But this was special code running under special conditions, and it was in cahoots with the kernel so the kernel didn’t freak out when it saw this wacko stack.»
Только не надо лгать.
Хороший совет — применяйте его почаще.

У вас даже просто признаться «я был неправ» кишка тонка.
Вот уж чего нет — того нет, извините. Если я где-то что-то путаю (как те же MS DOS и PC DOS) — то всегда признаю свои ошибки.

Это у вас с этим проблемы.

Вы «в курсе» стали только после того, как прочли мой комментарий и полезли гуглить.
Ну да, конечно. А пара лет развлечений с песочницей, на этом основанной — они мне приснились.

Поверьте мне: Windows становится крайне недовольна, когды вы SS трогаете в 32-битной программе. А если трогаете CS — то недовольными становятся уже некоторые процессоры (там правда, речь уже не об ошибках идёт, а о замедлении… радикальном-таком, раз в пять… но всё равно неприятно).
Ни о каком 32-битном ядре никто никогда не заикался, это даже не смешно.

Ну это вы не заикались. Большинство разработчиков всё-таки знают, что ядро Win95 гибридное, но конкретно та его часть, которая обеспечивает рабочее окружение, в частности, управление контекстами процессов, вытесняющую многозадачность, управление памятью — она 32-разрядная. Драйверы устройств — и 32-разрядные, и 16-разрядные. GUI — также и 32-разрядный, и 16-разрядный.
но ровно по модулю того, что вы эту чудесную многопоточность имеете пока не общаетесь с GUI

Я вам более того скажу, то вы с Delphi перепутали. Если лезть в многопотоке в графику в Delphi, то там действительно «все эти прелести» проявляются, но это проблема сугубо VCL. Если же вы в многопотоке полезете к виндовому GUI напрямую через API GDI32.DLL, то ваше приложение будет абсолютно нормально работать, без каких-либо «прелестей».
Если же вы в многопотоке полезете к виндовому GUI напрямую через API GDI32.DLL, то ваше приложение будет абсолютно нормально работать, без каких-либо «прелестей».
А давайте не будем рассказывать сказок, а? Вот тут Раймонд подробно про всё это рассказывает. Тут — описывает как он дебажился в Windows 95 с помощью Wyse 50.

Если вы ваша нирванна действительно была бы реализована в Windows 95 — то всё это было бы ненужным, извините.

Вот счётные задачи, которые ни с железом, ни с пользователем не взаимодействуют — это сколько угодно. А вот как GUI начались… так и всё, приплыли.
Вы видите то, чего нет.

По ссылке он рассказывает про AttachThreadInput — функциональность, специально добавленную для совместимости с 16-битными приложениями. В приложениях, которые не вызывали AttachThreadInput, не было никаких проблем с вытесняющей многозадачностью в GUI.
Вы видите то, чего нет.
Это вы видите то, чего нет… хотя это с какой стороны посмотреть, конечно…

В приложениях, которые не вызывали AttachThreadInput, не было никаких проблем с вытесняющей многозадачностью в GUI.
… до тех пор, пока какая-нибудь другая программа не вызывала AttachThreadInput.

Не обязательно ваша. Вообще любая.
Если вы ваша нирванна действительно была бы реализована в Windows 95 — то всё это было бы ненужным, извините.

Вообще, он там про отладку 16-битных приложений пишет, так, к слову. Подсистема Win16 в 95-й винде, это отдельный мирок, живущий сам по своим правилам, перенесенный в общую область адресного пространства без особых изменений из винды 3.х. В том числе и с одной общей очередью сообщений для 16-битных приложений.
В 32-битных потоки имеют раздельные очереди сообщений, кроме крайне редких случаев использования AttachThreadInput, как уже написал tyomitch. А сама GDI32.dll, например, щедро усыпана критическими секциями, чтобы избежать конфликтов при манипуляции ресурсами из разных потоков.
zanuda on. ну как раз про win95. не имею в виду win95osr2 и поздние. у первой часть вызовов и консольные win приложения шли с переключением туда-сюда через 16 битный сегмент.
чистый win32 это натянутый win32s, а позже win95 на ядро полуоси — Win Nt.
4004 имелась в виду что расширенная версия его в 8 битном — 8008, позже 8080 как раз использовалась как база в т.ч. и для CP\M пэвм.
zanuda off.
даже в вин-нт 4.0 натягивая интерфейс win95 на 32 битное ядро — убили эту многозадачность в графической подсистеме, вплоть до winxp 32 бит точно.
и падение в ней приводило к падению системы. в более ранних 32 битных, Win NT, вплоть до 3.51 это один из сервисов, и его отвал не приводил к отвалу системы.
НЛО прилетело и опубликовало эту надпись здесь
По вашей ссылке указано, что ядро NT создавалось именно в качества «ядра полуоси», хотя так им и не стало.
Так что общего кода у них действительно нет, а вот общей истории очень много.
НЛО прилетело и опубликовало эту надпись здесь
Цели, в смысле рыночная ниша (рабочие станции) — были одинаковые.
Если бы MS и IBM не поссорились, то NT 4.0 вполне могла бы называться OS/2 4.0
НЛО прилетело и опубликовало эту надпись здесь
А может вместо того что-бы выдавать на гора благоглупости, с сайта, контент которого открывается через вебархив, лучше изучить историю вопроса, техническую документацию и внутреннюю конкуренцию в департаментах IBM? Короче если вкратце, то во всём виноваты наполеоновские планы руководства IBM и яростное сопроотивление разработчиков той-же AS/400 (Об этом у Солтиса хорошо описано) попыткам разработать единую OS для всех IBM-овских машин, начиная от PC и заканчивая мейнфреймами. Именно поэтому OS/2 PPC Ъ микроядерная, мультисерверная, и из коробки поддерживает запуск win3.x и DOS приложений на PPC.
ЧСХ HPFS и ранняя NTFS похожи до степени смешения. Но MS, в те времена, не осилила довести NTFS по фичастости и надёжности даже до обычной HPFS, не говоря уже о серверном варианте HPFS386. Да и ядро NT это лютая смесь наработок по ядру OS/2 и ядру VMS.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
MC 68008 с восьмибитной шиной данных существовал, но из-за отсутствия конвейера команд очень сильно проигрывал в производительности 68000, плюс первая ревизия в DIP адресовала только 1 мегабайт. Потом с заменой корпуса адресацию довели до 4 мб. И цена у него была не намного меньше чем у 68000. И к созданию IBM PC он опоздал (представлен 1982). И ЕМНП с совместимостью с 68000 там тоже было не все ровно. Так что получился довольно таки странный проц: 16 разрядное АЛУ, 32 разрядные регистры, восьмибитная шина данных.
«От белых отбился, и к красным не пристал.»
И тогда история архитектуры 8086 была бы другой, без ограничения в 640кБайт памяти, и многого другого.

Ограничение 640К памяти в общем-то лежит не в ответственности архитектуры 8086, а на совести того чувака, который проектировал распределение памяти в IBM PC. Ну и с другой стороны, что плохого в ограничении 640К в то время, когда хорошая персоналка имела 16К, а крутая профессиональная — 64К?
Конкретная цифра 640К — да, заложена в архитектуре, но само появление этого ограничения вызвано максимальным размером адресуемой памяти для 8086 и 8088 — 1024кБайт. IBM PC с самого начала поставлялась в конфигурациях с объёмом памяти до 256кБайт — то есть запас по адресному пространству — всего в 2,5 раза. А ведь закон Мура на тот момент исправно работал уже 16 лет.
IBM PC с самого начала поставлялась в конфигурациях с объёмом памяти до 256кБайт — то есть запас по адресному пространству — всего в 2,5 раза

Ну и современные компьютеры тоже обычно имеют не так чтобы уж десятикратный запас по расширению памяти :)
1024 килобайта — это было очень много во время появления этих процессоров. И более того, это было вполне достаточно и через десять лет после их появления для подавляющего большинства применений персональных компьютеров. А для тех применений, где недостаточно, легко можно было пойти тем же путём, которым пошли восьмибитки — страничным расширением памяти.
Страничная память — это очень неудобный в использовании вид памяти, очень немногие программы её поддерживали на PC.
Те, кому надо было, использовали. В конце-концов, что там такого неудобного в свете того, что основное адресное пространство и так использовалось 64-килобайтными сегментами?
Неудобно в первую очередь использовать страничную память для исполняемого кода — код, выполняющийся на одной странице не мог напрямую вызвать код на другой странице — только через драйвер. Основное адресное пространство использовалось сегментами, но эти сегменты могли иметь любой размер, кратный 16 байтам, не более 64К — а страницы имели фиксированный размер.
Хочешь жить — ещё не так раскорячишься. Но да, это было проблемой. Впрочем были и решения: гуглите OvrInitEMS.

Да, больше 2-4MB так было использовать нельзя, скорость падала сильно… но какое-то время это работало.

В конце-концов Unix на PDP-11 как-то с этим жил… а чем MS-DOS хуже?
Если Вы про «кольца» защиты памяти — то это уже 386 архитектура (с появлением соответствующих битов защиты) и IBM OS/2. В MSDOS на 8086-архитектуре НЕ БЫЛО проблем/ограничений в работе с памятью в пределах первых 640КБ. Например, прямая запись в видеопамять (и чтение оттуда, есличо) была чуть ли не штатным решением для DOS-программ (ибо работало быстро,- намного быстрее чем через прерывания DOS). Проверено на TurboPascal и MASM ;). А наличие прямого доступа к стеку позволяло делать вообще всё что угодно,- вплоть до произвольного блуждания по ОЗУ и вызовов чего угодно откуда угодно. Наличие в DOS возможности TSR (Terminate&StayResident) позволяло писать свои хитровыделанные утилиты,- к ним можно было обращаться даже из ранних версий Win. Про OS/2 ни чего сказать не могу. Даже не помню, была ли она для машин младше 386-ой серии. Если речь идёт про expanded|extended memory,- то да, там ставились драйвера, которые «хитрили» с адресными регистрами и проч.,- для доступа ЗА пределы первоначальных 640К (через сегменты-«окна»). Но это началось начиная с 286-ых процессоров, кажется (коих было немного). Ещё были «вроде как промышленные» 80186, но я их не видел. ;)
НЛО прилетело и опубликовало эту надпись здесь
Если речь идёт про expanded|extended memory,

Expanded и expended память — это несколько разные вещи, и первая как раз работала через окно, и в том числе и на 8086 (собственно, для подобного подхода тип процессора и не важен). Что касается защиты памяти, это уже появилось в 286-х, если мне память не изменяет, равно как и возможность переключиться в режим с линейным адресным пространством до 16 мегабайт.
Я про EMS/XMS и подобные расширители памяти, которые сначала шли в комплекте с ISA-картами-расширителями памяти, а позже, на 286 и выше — обеспечивали доступ к памяти за пределами 640кБ. Я говорю о том, что ограничение адресного пространства в 1МБайт, вызванное 20-битным адресом 8086, приводило к тому, что даже на 486 многие программы под DOS не могли адресовать больше, чем 640кБайт. Потому что работать через эти драйвера было неудобно.
И я про них же :) EMS работает через окно, XMS в общем случае через менеджер памяти, но почему неудобно-то? Работа с XMS-памятью через DPMI не особо отличается от работы с любым другим менеджером памяти и в рамках традиционных 640К. Запросил блок, получил дескриптор, сохранил данные, считал данные, освободил блок. Всё как и раньше. Просто масса софта и в 90-е вполне помещалась в 640К, вот и не заморачивались.
Если в этой памяти хранить данные — это ещё более-менее нормально. Сложно разместить там исполняемый код.
Для кода был DPMS.
Вот только появился он только в 92-м году, когда уже выпускался 80486DX2, а PC/AT, в котором могло быть до 16МБ памяти, уже успели снять с производства.
Я думаю, не ошибусь, если скажу, что проблема нехватки 640К для кода приложений вообще только в начале 1990-х и стала как-то проявляться, и то не благодаря DOS, а благодаря Windows. А 16 мегабайт памяти в среднестатистическую персоналку пришли только в 1996-м году, уже в эпоху Пентиумов.
Согласно таблице, упомянутой @khim, уже в 1986 году стоимость оперативной памяти упала до $190/ мегабайт. То есть домашний компьютер вполне мог иметь 2..4МБайта памяти (за $380..$760), а рабочая станция — 8МБайт (за $1520) — по цене, вполне адекватной стоимости остального железа (но не для СССР, конечно). Но немногие программы могли использовать столько памяти — как раз из-за упомянутых проблем, потому и немногие компьютеры её имели.
То есть домашний компьютер вполне мог иметь 2..4МБайта памяти (за $380..$760)

Хочу напомнить, что $760 в 1986-м — это больше половины среднемесячной заплаты американца, не говоря уже про остальные страны. И это только память. Вы думаете, количество домашних компьютеров ценой в несколько американских зарплат в мире статистически было заметно больше нуля? ;)
Типичный объем памяти домашнего компьютера в 1986-м году, это 64/128 килобайт, и среди них IBM PC, к слову, практически не встречается. По двум причинам:
а) это профессиональный сегмент с конской ценой
б) у РС, представьте себе, в 1986-м году нет звука и нет хорошего видео за приемлемую цену, а у 8-битных машинок всё это есть.
Профессиональные компьютеры — до мегабайта. Очень редко, за космические деньги, встречались более навороченные машины с бОльшим объемом памяти, для каких-то узких профессиональных применений, например, 3D графика или там издательское дело. И в массе своей они вообще не x86 и не под DOS.
Разумеется, я говорю только о 16/32-битных компьютерах, соответственно, домашний компьютер — имеется в виду из дорогого сегмента, не для среднего американца. Звук на PC в 1986-м уже был — примитивный, в виде Covox. А в 1988-м появились и нормальные звуковые карты от Creative и AdLib. EGA появился в 1984-м, VGA — в 1987-м.
Я о том и говорю, что не x86 и не под DOS — потому что на x86 и под DOS критическим было ограничение адресного пространства.
Я о том и говорю, что не x86 и не под DOS — потому что на x86 и под DOS критическим было ограничение адресного пространства.
Нет. Потому что столько памяти не было.

Я как-то обсуждал это с Шенём. Он, сам лично, в 1988м привёз DIP-микросхем, чтобы добить у них в классе на PC'шках память до 512K и запустить, наконец, среду Turbo Pascal 4.0. До этого там была «повинная память» (256K) и можно было использовать только компилятор командной строки, для среды памяти не хватало.

Вообще до 1987го границей не 640K считалась, а 512K. Штатно ни в XT, ни в AT (базовые модели) больше 512K не ставится, ещё 128K нужно доставлять на дочерней плате. Ну или по инструкции которая включает в себя, помимо прочего, покупку «small length of thin gauge jumper wire» и «install a jumper wire from pin 1 to pin 8 on U44».

Вот в 1987м — там да, появился PS/2, многие модели уже имели 1MB штатно (вначале под электронный диск, с 1991го года под DOS в HMA)… но мы уже к 1990м подбираемся.

Глядя на даты, когда появлились те или иные вещи вы забываете скорость внедрения всего этого добра. Это сейчас — если объявление о появлении процессора появилось, то это значит, что производители материнок уже их клепают и скоро он будет уже у покупателей. В те годы всё было не так.

8086й — появился в 1978м, через год — появилась удешевлённая модель, а ещё через два года — IBM PC. 80286й — появился в 1982м, а IBM PC AT — вышла в 19284м, 80386й — это 1985й, но IBM PS/2 с ним — это 1987й (а Compaq DeskPro хотя и вышел в 1986м, но долгое время о нём большинство пользователей только лишь в газетах читали).

В общем то, что DPMS появился в 1992м, а не в 1987м — это скорее потому что массовый потребитель в нём тогда стал нуждаться.

OS/2 1.0 появились в 1987м, но требовала 2MB памяти (а поддерживала 8MB… причём рекламные материалы говорили про 16MB, но IBM элементарно не проверила её на таком гигантском объёме — она тупо падала при загрузке).
Штатно ни в XT, ни в AT (базовые модели) больше 512K не ставится, ещё 128K нужно доставлять на дочерней плате.

В XT — может быть, но AT сразу продавалась с возможностью расширения памяти до мегабайтов.
Она, внезапно, вставала как 512K «обычной» и 512K расширенной. Вот тут это всё подробно обсуждалось.

На поздних моделях есть переключатель, чтобы было 640K+384K, но изначально идея была в том, чтобы строго следовать спецификации IBM PC, которая выделяла половину адресного пространства под память, половину — под устройства и ROM.
соответственно, домашний компьютер — имеется в виду из дорогого сегмента, не для среднего американца.

Ну так какой смысл говорить о том, что своим числом было близко к нулю? Даже игр, контент которых требовал больше 640К памяти, тогда не существовало.
Хочу напомнить, что $760 в 1986-м — это больше половины среднемесячной заплаты американца, не говоря уже про остальные страны. И это только память. Вы думаете, количество домашних компьютеров ценой в несколько американских зарплат в мире статистически было заметно больше нуля? ;)

Хочу напомнить, что IBM PC/AT (1984, 512K RAM) стоил $5,795.
При такой цене аппаратуры, $760 за память — это не очень существенно.
При такой цене аппаратуры, $760 за память — это не очень существенно.

Наверное, мы немного по-разному мыслим. Для меня лишних ползарплаты из моего кармана как-то не уменьшают свой размер, если я покупаю что-то очень дорогое :)
а PC/AT, в котором могло быть до 16МБ памяти, уже успели снять с производства.
PC/AT сняли, а вот всякие PS/2, во многие из которых вставало максимум 4MB или 8MB — как раз в самом разгаре.

Не знаю, кстати, почему случился такой откат: BIOS от PC/AT отлично «переваривает» 16MB, а вот многие более поздние модели — не могут.

Но его явно бы не было, если бы эта память была востребована.
OS/2 1.x была заточена под 286-е процессоры.
И тогда история архитектуры 8086 была бы другой, без ограничения в 640кБайт памяти, и многого другого.
Ага. А ещё она была бы очень короткой.

Как бы все знают о том, что в 90е годы IBM PC прошёл через «дольшой надлом», когда произошёл переход от MS-DOS (с пресловутым «барьером 640KB») через Windows 9X к Windows 2000 (и её потомкам).

Но не все осознают, что все персоналки, абсолютно неизбежно должны были через такой слом пройти. И как раз ограничение в 640K позволило платформе IBM PC пройти его самым оптимальным, практически идеальным, способом.

В чём фишка? В операционке. Современные операционки (все: Darwin/MacOS, Linux, Windows) — это операционки, где программы изолированы от железа.

Сколько занимает такая операционка? Ну… насчёт самого-самого минимального объёма можно спорить, но все реально существующие операционки такого класса требовали 2-4MB памяти (современные требуют больше, но не сильно, вроде бы даже последние версии Linux требуют от 8MB… а уже самые ранние версии OS/2 требовали 2MB).

А ранние персоналки продавались с 16K-64K! Ну просто цена бы у них была непомерной, в противном случае.

Соответственно все без исключения ранние персоналки — никак не изолировали программы от «железа». Ибо возможности не было.

А перенос программы, которая лезет куда можно и куда нельзя на платформу, где это делать не получится… вещь тяжёлая, однако. Фактичеки — невозможная. Программу придётся просто переписать.

И вот так получилось, что единственная платформа, которая в принципе могла это пережить — это была платформа на базе 8086.

Потому что когда дошли до предела в 640K, то, разумеется, никто никуда переходить не захотел: нам тут нужно бухгалтерию бухгалтерить и книжки печатать, а вы хотите всех заставить переучиваться? Вы, вообще, в своём уме?

Придумали костыли. А потом — ещё другие костыли. И несколько лет продержались.

Но в конце-концов всё-таки дальше «растягивать» платформу стало невозможно.

И как раз тут — появилась Windows 95, которая, с одной стороны, неплохо дружила со всей этой коллекцией костылей, а с другой — позволяла, наконец-то, писать программы, которые могут, без проблем, использовать десятки, сотни, мегабайт памяти!

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

А вот у всех других платформ — переход не случился. Восьмибитные было невозможно «растянуть» до 2-4MB, они кончились гораздо раньше, в большинстве своём. Мало кто добрался даже до 1MB.

А 32-битные… там как раз другая беда: переходить на новую платформу ради работы с большим количеством памяти было не нужно… а без этого — всё это продолжало страшно «глючить» и «падать».

Единственная платформа, которой этот переход всё-таки удалось сделать, Macintosh сделал это буквально чудом, когда уже все отчаялись и разочаровались — но использованный там изначально CPU этого перехода не пережил…

Какой, нафиг, барьер в 640К? Это только на 8088/8086 есть этот барьер.


Две из трёх лидирующих платформ 90х никогда не имели барьера в 640К, потому, что собирались на отличном мотороловском 32-битном процессоре 68000. У которого, между прочим, отличнейший ассемблер, похожий на мощнейший ассемблер PDP-11.
И операционки на этих платформах были совсем не MSDOS, а вполне себе многозадачные.


Единственное преимущество IBM-PC — это цена. То есть, вся наша IT индустрия обязана пиратам из Compaq, которые склонировали PC в 82 году.


Кстати, 68000 был запрещён к ввозу в СССР, а впоследствии и в Россию, до 1995 года.

Две из трёх лидирующих платформ 90х никогда не имели барьера в 640К

Вы о чем вообще — это барьер родом из 80-ых, в 90ые на Западе 8086 был давно не актуален.
До появления Windows 95 даже 486е использовались, зачастую, как «быстрые MS-DOS машинки». «Старые добрые» Borland C++ 3.1 и Turbo Pascal 7.0 — это 1992й. И, поверьте, Turbo Pascal 7.0 не зря вернулся к «синим окошкам»… Turbo Pascal 1.0 for Windows (вышедший в 1991м) особым успехом не пользовался. Да и Visual Basic 1.0 for DOS (1992й) и Microsoft Word 6.0 for DOS (1993й) вряд ли бы появились, если бы в 90ые все уже давно отказались бы от MS-DOS.

Вот после выхода Windows 95 — да, там был лавинообразный переход. Уже к 1997му доля MS-DOS упала ниже 50%. А до этого… MS-DOS держался стойко. В конце-концов как в DOOM-то играть? Quake — это уже 1996й (и даже он, внезапно, изначально вышел только в версии для MS-DOS!)

вся линейка 9х была с досом. 95я, если правильно помню, как и 3.х это надстройка над дос, 98 вроде бы имела дос, но не знаю на чём всё работало. А вот "линолеум"… Песня! Матерная.

DOS в составе Win9x хоть и был, но при работе не использовался.
Ещё как использовался! «Режим совместимости с вирусов», как его у нас в школе называли.

Когда Windows 95, при загрузке обнаруживала, что у неё INT13h ведёт не в BIOS, а куда-то в оперативку… она решала, что кто-то юзает хитрый SCSI и начинала вместо своего 32-битного драйвера ходить на диск через INT13h.

На практике это, конечно, случалось, когда кто-то приносил загрузочный диск с вирусами и умудрялся с него загрузиться (спасибо чудесному BIOS от «настоящей IBM», не позволяющему загрузку с дискет отключить).

Скорость работы снижалась настолько, что казалось, что ты, внезапно, пересел c Pentium II на 80386й…
Ещё как использовался!

Ну это же типа «аварийный режим», это как у автомобиля вместо колеса докатку поставить, ведь от этого порше в жигули сразу не превращается, типа докатка-есть? есть… всё, жигули, а не порше, неважно что она просто в багажнике лежит
НЛО прилетело и опубликовало эту надпись здесь
Мы только в 2005 мигрировали с FoxPro 2.6 на VFP6. Причина — массовая гос-закупка лицензий на WinXP (с отмыванием соотв). В результате — пострадала производительность. На все машины что подходят под «минимальные требования» в обязательном порядке был установлен winXP. В результате, там где раньше и 98 не очень бодренько грузился, стало совершенно невозможно дождаться загрузки.
НЛО прилетело и опубликовало эту надпись здесь
До сих пор не могу понять: как получилось, что такие продвинутые системы проиграли борьбу x86 и DOS/Windows 3.1
Я ниже описал как.

Ведь они появились намного раньше, и были во многих отношениях (во всех?) намного более продвинутыми.
Единственное, что у них было круче — это «метафора рабочего стола». Которая, внезапно, даже у 8-битной GEOS имелась, а вот у Windows — отсутствовала (в попытке избежать судилища с Apple… которое, впрочем, всё равно случилось).

Больше никаких принципиальных преимуществ у них не было, а вот библиотека программ — была крайне куцей. Macintosh сумел «урвать» рынок препринта (Desktop Publishing), Atari ST — работу со звуком (Cubase и прочие), Amiga — работу с видео (DraCo с сотоварищи). Но надолго их не хватило: доля всех этих систем вместе взятых никогда не превышала ¼, а после того, как вышла Windows 3.1 всё это богатство начало быстро переезжать на IBM PC.

Ну а после появляения Windows 95, когда у вас на PC был уже и весь софт (его-то портировали раньше) и, наконец-то, нормальный GUI… зачем все этим «типа как продвинутые» (на самом деле нет) системы могли быть кому-то нужны?

Помню, насколько был впечатлён графической оболочкой этой системы, а также ее возможностями. От всяких MSDOS поделок, с которыми приходилось иметь дело, казалось, её отделяли световые годы.
О да! Секрет айсберга, как он есть: Люди, которые не являются программистами, смотрят на экран и видят какие-то пиксели. И если кажется, что эти пиксели могут собраться в программу, которая что-то делает, они думают «да ну, сколько там ещё осталось, чтобы она просто начала действительно работать

Когда непрограммисты смотрят на две эти картинки:


И их спрашивают о возможной судьбе этих систем… то они, как правило, отдают предпочтение первой: она же удобная, красивая, Drag-N-Drop и всё такое.

Когда на них же глядят программисты… ну это ж даже не смешно! Ну честное слово! Сравнивать поделку на коленке с первой картинки с реальной операционкой на второй? Ну это всё равно что сравнивать кто выиграет в бою между Майком Тайсоном и первоклассником. Что тут вообще обсуждать-то?
Тем не менее, сейчас даже совсем-совсем программисты с большим удовольствием используют наследие макоси с верхней картинки.
Ну и многие программисты, которые ни в коем роде не дизайнеры и не обладают утончённым художественным вкусом, и то отмечают что яблочные операционки выглядят очень аккуратно и приятно и что использование их приносит удовольствие.
Тем не менее, сейчас даже совсем-совсем программисты с большим удовольствием используют наследие макоси с верхней картинки.
Маркетинг… это круто, не спорю. Но ничего, что в том «наследии», которое они используют нет вообще ничего, унаследованного от одномённой операционки? Даже иконок.

Все программы были переписаны — точь-в-точь как при переходе с MS-DOS на Windows, собственно.

Ну и многие программисты, которые ни в коем роде не дизайнеры и не обладают утончённым художественным вкусом, и то отмечают что яблочные операционки выглядят очень аккуратно и приятно и что использование их приносит удовольствие.
Ну это уже совсем-совсем другая история. Я общался и с MacOS Classic (когда-то давно, в школе) и с MacOS X (не так давно) и в обоих случаях плевался.

Тут я скорее о том, что MacOS Classic Apple так и не смог «довести до ума», пришлось покупать готовое решение в совсем другой компании и надеяться, что замена «прокатит».

Ни о какой наследственности там речи и близко не идёт, при переходе было выкинуто вообще всё, что можно выкинуть.
Я общался и с MacOS Classic (когда-то давно, в школе) и с MacOS X (не так давно) и в обоих случаях плевался.

С первой познакомился в конце 1994 года. Ощущение было… Ну как обои переклеивать через замочную скважину. Файлы не найти, всё мышкой и никак иначе. В общем, кривее системы я не видел. Потому подходил в магазинах к стендам, смотрел — улучшений не замечал. Потом, 2013 году, 9 месяцев проработал уже на OS X. Это была БОЛЬ: «мультики» не отключаются, переключатель экранов одномерный, а развёрнутая на весь экран программа занимает отдельный экран, то есть логика переключения ломается нафиг. В общем, даже MS Windows на этом фоне выглядела шедевром.
Сравнивать поделку на коленке с первой картинки с реальной операционкой на второй?

Чушь какая-то. Уродливое поделие Win3.1 с такой же кооперативной многозадачностью как у максоси не вызывает никаких эмоций кроме рвоты :)
Ну вот видите — даже вы не можете заметить надписи «Windows NT Setup», упоминаний про «COMP2\Administralor» на второй картинке и понять, что там многозадачность — ни разу не кооперативная и в операционке — есть и пользователи и защита.

А как безному юзверю это понять?
Это не важно. Мой пародийный пост — это просто намёк, что бы вы посмотрели со стороны на свои посты.
«богатеньких лохов»
«поделку на коленке»
«и в обоих случаях плевался.»
Непонятный хейт платформ Apple, это какая-то детская обида?
Или вам действительно нравится убогий дизайн UI, кривая системная архитектура, сегментные регистры и т.п.?
Или вам действительно нравится убогий дизайн UI, кривая системная архитектура, сегментные регистры и т.п.?

А чем плох дизайн UI винды, и тем более чем плохи сегментные регистры для своего времени, если иметь в виду тот факт, что как раз не в последнюю очередь благодаря наличию сегментных регистров х86 стала доминирующей архитектурой, вынеся с рынка своих конкурентов с такой удобной линейной адресацией. Собственно ради чего они и задумывались.
Непонятный хейт платформ Apple, это какая-то детская обида?
Во-первых причём тут платформы Apple, а во-вторых — почему вы решили, что я на кого-то обижен?

«богатеньких лохов»
«поделку на коленке»
«и в обоих случаях плевался.»
И, что самое забавное, во всех этих случаях — я могу указать, почему, объективно, вот это вот всё заслуживает ровно таких эпитетов.

Мой пародийный пост — это просто намёк, что бы вы посмотрели со стороны на свои посты.
Я прекрасно знаю как мои посты выглядят со стороны. Как что-то написанное очень нетолерантным и неполиткорректным человеком.

Потому что я такой и есть. Если я вижу вонючее дерьмо — я говорю: тут — дерьмо… и оно пахнет. И мне плевать на то, что я могу, тем самым, поранить чью-то ранимую душу.

А уж то, как как Apple «окучивает хомячков»… тут у меня просто душевный трепет: умудриться продать людям смирительную рубашку, не позволяющую вам отклониться от «генеральной линии партии» ни на йоту под слоганом Думай иначе — это просто высший пилотаж.

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

Вот рассмотрите всю нашу дискуссию. Не один мой пост, а всю её в целом.
Я: Резкий, на грани фола, наезд на macOS Classic
Вы: Ложь и неправда
Я: Извините, но вы врёте
Вы: Это неважно

Нет уж ребята — вот именно только это и важно. Факты — это то, что рулит миром. Если у вас, условно говоря, доходы с разходами не сходятся, то можно достаточно долго водить всех за нос… но в конце-концов, в истории, вы-таки останетесь мошенником.

Вот, собственно, и всё. Если у вас есть факты или я где-то, в чём-то, фактически ошибся — можно разговаривать. Если у вас есть «оценки» и «мнения»… оставьте их себе.
И операционки на этих платформах были совсем не MSDOS, а вполне себе многозадачные.
Они были многозадачными, но они не были защищёнными. Там была кооперативная многозадачность и чем больше задач вы запускали тем больше становился шанс у всего этого «свернуться в трубочку и упасть на пол» — вместе со всеми задачами и процессами.

Именно потом что эти «две из трёх платформ» (кстати почему «две из трёх?»… Atari и Amiga продавались сравнимыми тиражами) родились в 1980е. Когда защита никак не вписывалась в имевшиеся ресурсы.

Единственное преимущество IBM-PC — это цена.
Это у C64 и Apple ][ единственное преимущество — цена. Что, кстати, позволило им неплохо-таки держать до 1984го: C64 продавалось больше, чем IBM PC вместе со всеми клонами, а Apple ][ — больше чем IBM PC, но меньше чем IBM PC с клонами.

То есть, вся наша IT индустрия обязана пиратам из Compaq, которые склонировали PC в 82 году.
Apple ][ тоже клонировали. А уж сколько клонов Spectrumа народ насоздавал… не в сказке сказать, ни пером описать. MSX вообще открытым стандартом был. C64 не клонировали только потому, что Трэмел банально купил MOS Technology и тем самым сделал это мероприятие крайне проблемным.

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

Потому все восьмибитные платформы вымерли до того, как защищённый режим стал быть не только теоретически возможным, но и реально доступным. Да, уже даже на 68000 (двух из-за известных проблем) какие-то компании делали Unix-системы, а на 68010 это даже стало достаточно просто, но… они стоили заоблачных денег и с персоналками никак не пересекались.

А вот MS-DOS смогла «дотянуть» до момента, когда можно было скакнуть от примитивных текстовых программ к 32-битным программам для защищённого режима.

В результате вместо двух переходов на всех остальных платформах (которые большинство их них просто не смогли пережить… AmigaOS 4 это, всё-таки, «жизнь после смерти») на платформе IBM PC переход был один. Да, он был очень длительным (начали в 1993м с появлением Windows NT, закончили в 2001м с появлением Windows XP) — но при этом ни в какой момент пользователям не приходилось сталкиваться с тем, что их библиотека накопленных программ, вдруг, «превратилась в тыкву».

Конечно можно себе представить и другой мир. Мир, где Apple не делает идиотских движение и вместо дёрганий с Apple III, Apple Lisa и Macintosh переходит прямо к Apple IIGS — причём форсированно, в 1983м… а потом WDC выпускает какой-нибудь 65832… тогда, возможно, был бы шанс повторить путь x86 и через промежуточную модель (у x86 это был 80286) перейти от 8 бит к 32 битам без потери библиотеки программ…

Но история не знает сослагательного наклонения — случилось то, что случилось.

И случилось, во-многом, именно потому что 8086 позволял адресовать 1 мегабайт, но не позволял адресовать 4 гигабайта.

Если бы не это — массового перехода на 32битные OS (с точки зрения прикладных программ Windows 95 — вполне полноценная OS с защищённым режимом) в 1995-1996м (когда, как раз, все конкуренты боролись с тем, что все их красивости «рассыпались как дым» от одного неосторожного движения мышью) не случилось бы. Он всё равно случился бы — но позже… то есть опять-таки — у альтернативных платформ появился бы шанс.

Кстати, 68000 был запрещён к ввозу в СССР, а впоследствии и в Россию, до 1995 года.
С 8086 тоже всё было непросто. Кажется у Pentium существала специальная версия «с особо пониженными частотами», которая вписывалась в ограничения… её на выставках в России показывали… но когда они пошли в серию это уже не было проблемой.

В любом случае — сам переход на 68000 был проблемой. Именно на этом переходе все альтернативные платформы «потеряли темп». До этого (суицидального, как потом выяснилось) перехода доля PC-совместимых персоналок никогда не превышала ⅓. После этого перехода — она никогда не снижалась ниже ¾.

Максимум чего всем альтернативным платформам вместе взятым удалось добиться после этого перехода — было 23.21% в 1991м.
Если бы не это — массового перехода на 32битные OS (с точки зрения прикладных программ Windows 95 — вполне полноценная OS с защищённым режимом) в 1995-1996м (когда, как раз, все конкуренты боролись с тем, что все их красивости «рассыпались как дым» от одного неосторожного движения мышью) не случилось бы. Он всё равно случился бы — но позже… то есть опять-таки — у альтернативных платформ появился бы шанс.

32-битные OS это не 95 год, а 85. И ничего ни у кого не рассыпалось от неосторожного движения мыши, всё работало, никто не жаловался.

32-битные OS это не 95 год, а 85.
В этом и беда, мой друг, в этом и беда. В 1995 Microsoft еле-еле, но сумел вписать операционку с полноценным защищённым режимом для программ в приемлемые, для того времени, 4-8MB. А в 1985м — об этом можно было только мечтать. И в результате все эти «32-битные OS» — это общее адресное пространство для всех программ и кооперативная многозадачность (строго говоря Amaga поддерживала и вытесняющюю, но на практике получился гибрид с худшими чертами обоих: медленее, чем кооперативная, но при этом, поскольку защиты памяти всё равно нет и любая программа может всю эту «вытесняемость» остановить к чертям — без возможности поддерживать многоядерные системы).

И ничего ни у кого не рассыпалось от неосторожного движения мыши, всё работало, никто не жаловался.
Вот только не надо сказок, а? У нас в школе были старенькие Маки, куда MacOS не вставала. Там я это «ни у кого не рассыпалось» наблюдал воочью. Запустите десятка два программ (особенно не самых популярных и «вылизанных с годами») — и наблюдайте всеми обожаемую бомбочку (ну или Guru Mediation, если у вас Amiga).

Да, если новых программ не ставить и составить ментальную карту «вещей, которые не нужно делать» — то можно как-то жить. Но это по качеству жизни — близко к уровню к MS-DOS… или Windows 95. Но никак не к Windows NT/2000/XP.

И если в случае с Windows 95 все понимали «да, это, конечно, трэш и угар… но как скопим денег — поставим Windows NT и проблемы решатся… может даже пару процессоров удастся прикупить» (Windows NT вышла раньше Windows 95, напоминаю… и сразу поддерживала и DEC Alpha и SMP)… то у всех альтернатив… ничего подобного не было: было понятно, что глюки так и останутся глюками — а что будет через 3-5-10 лет… понятно не было.

Очередная «система без будущего», как и с 8-битками за 10 лет до того.
В этом и беда, мой друг, в этом и беда. В 1995 Microsoft еле-еле, но сумел вписать операционку с полноценным защищённым режимом для программ в приемлемые, для того времени, 4-8MB.

Ну так Майкрософт еле-еле сумел вписать её туда не потому, что полноценный защищённый режим — это так сложно, а потому, что вместе с полноценным защищённым режимом там ещё должен прилагаться мощный по тем временам оконный менеджер, мультимедийные возможности, довольно тяжёлые системные API, да блин даже обои на рабочем столе 800x600 в 16-битном цвете, это, минуточку, мегабайт памяти. У IBM появилась операционка с защищенным режимом и с поддержкой виртуальных машин ещё тогда, когда Intel переходил с четырех бит на восемь. И этой операционке с большим запасом хватало, минуточку, 512К ферромагнитной памяти среднего мейнфрейма тех лет. Но да, там красивых окошек не было, был вездесущий зелёненький терминал 3270
Всё так, но в данном, конкретном, случае, разница между 512K и 4MB непринципиальна. Всё равно это гораздо больше, чем можно комфортно впихнуть в 8 битную систему с 16-битной адресной шиной. Да, я знаю, в PDP-11 впихивали… и даже Unix там «ходил» — но, опять-таки, с теми самыми зелёненькими терминалами и, как бы это сказать… «на пределе». Графику пришлось-таки добавлять уже на 32-битных системах.

Это достижение, кстати, Microsoft, теоретически, даже повторил — но практически это, всё-таки, чисто исторический курьёз…

В любом случае: даже если бы в 512K и удалось что-либо упихать таки сама платформа должна была поддерживать больше, потому как потребности-то растут каждый год и переход на платформу, которой больше некуда «расти» — довольно глуп.

На IBM/370 512K было, скорее, начальной моделью, чем типичной. А C64 на этом объёме как раз закончился.

P.S. Мультимедийные возможности, кстати, мало кому были нужны в 1995м. Их даже Commodore особо в рекламе не упоминал, так как мало кто понимал для чего это можно приспособить (кроме как для игр).
Да, я знаю, в PDP-11 впихивали… и даже Unix там «ходил»

Да к слову, Unix в те годы не так чтобы далеко и ушёл от файловых мониторов уровня CP/M или DOS, разве что в идеологическом плане. А так, тогдашние юниксы ведь и на PC XT работали, где средства защиты в частности и многозадачности в целом отсутствуют как класс.
Ну дык и сегодня ведь есть и μClinux и FDPIC.

Но это «для сильных духом», всё-таки.
старенькие Маки, куда MacOS не вставала.

Что же там стояло?
Опечатка. MacOS X, конечно. Не помню что стояло. Classic macOS какой-то.

Так что m68k не только не был запрещен к ввозу, но и на его основе делались серийные машины. Стоили они дорого (по ведомости на 88 год около 200 тысяч советских рублей + 7 тыс рублей за каждый терминал), но ЗиЛ их прозвел достаточное количество и у нас в унверситете они жили до конца 90-х.

Скорее всего они ввезены через венгерский Videoton — очень мутная схема реэкспорта через третьи страны.


Более забавно, что через 10 лет Freescale чипы разрабатывались в Нижнем Новгороде.

Ограничение доступа к железу и виртуализация памяти и ввода-вывода были неизбежны для перехода к многозадачности, но их внедрение в процессоры не требовало отказа от существующего ПО — эта задача успешно решается перехватом обращений к разделяемым ресурсам по исключениям контроля доступа. Как раз хорошая расширяемость позволяет долго существовать параллельно старым и новым программам, в то время, пока преодолеваются детские болезни новой операционки с API, рассчитанным на многозадачность.
Ограничение доступа к железу и виртуализация памяти и ввода-вывода были неизбежны для перехода к многозадачности,
Изучите матчасть, пожалуйста. Mac (классический, конечно), AmigaOS, GEM (на Atari ST), да даже и ранние версии Windows (до версии 3.0 включительно) — отлично без этого обходились.

но их внедрение в процессоры не требовало отказа от существующего ПО — эта задача успешно решается перехватом обращений к разделяемым ресурсам по исключениям контроля доступа.
Теоретически да, практически нет. Одни циклы задержки чего стоят. Можете попробовать поиграться со старым софтом (1980х, не 1990х… в 1990х даже DOS-софт уже хоть немного, но под Windows тестировался и проблема стали не такой острой) — на old-dos его достаточно.

Какой-нибудь компилятор пакетный — запускается и работат без проблем. А вот уже что-нибудь интерактивное… да ещё с графикой… часто даже запусть не получается. Про знаменитую проблему c Runtime Error 200 даже Wikipedia пишет.

Сегодня-то да, можно без проблем эмулировать какой хошь процессор, хоть 4.77Mhz, хоть 100MHz и всё будет хорошо. А в момент перехода у вас такой роскоши нету…

Это ещё если железа нет специфического (ключа защиты, ага). Если же есть… то хоть как-то работает только подход Windows95: позволить программе на MS-DOS, фактически, единолично распоряжаться компьютером, а уж вся эти 32-битная «фигня» — пусть работает по прерываниям, когда «типа как TSR» берёт управление на себя…

Так что оба перехода — крайне болезненны… и к многозадачности и к защищённости.

Однако на x86 с точки зрения разработчика прикладных программ — переход был один: до Windows 3.1 большинство программ были под MS DOS, а начиная с Windows 3.1 — там уже сразу и многозадачность и защищённость (дырявая, да, но...)
Я в курсе, как работал механизм кооперативной многозадачности в первых версиях Windows. Неизбежен — не значит обязателен, я имел в виду, что этот переход обязательно произошел бы и в случае, если бы 8086 сделали бы 32-разрядным — потому что изолированность программ нужна для стабильности работы в условиях, когда программы не тестируются разработчиком ОС на совместимость, как это практикует Apple.
Совершенно верно — слом всё равно был бы был, однако в этом случае x86 пришлось бы пройти через те же, примерно, два «классических» слома, что и все остальные платформы: вначале — GUI, потом — защита.

Потому что у базовой модели IBM PC на GUI, как бы, тоже памяти не хватало — 16K и всё, хоть какая там у процессора битность.

Именно вот эта странная конструкция с сегментами привела к тому, что первый переход случился позже, второй — раньше, а в итоге — вместо двух переходов случился один.
НЛО прилетело и опубликовало эту надпись здесь
Операционки вроде DOS не делали изоляцию железа по одной простой причине — процессор это не поддерживал.
Вы это сейчас серьёзно? Попробуйте, на досуге, сделать операционку с защищённым режимом и посмотрите сколько памяти она потребует. Учтите, что базовая версия IBM PC имела 16KiB оперативки и 8KiB ROM.

Успехов.

P.S. У IBM и Microsoft как-то меньше, чем в 2MB вписаться не удалось (OS/2). Но может у них там дураки сидят. Windows 286 и та требовала минимум 512KB и жёсткий диск впридачу.
НЛО прилетело и опубликовало эту надпись здесь
Например, через внешний аппаратный менеджер памяти. На PDP был такой.
НЛО прилетело и опубликовало эту надпись здесь
Полагаю, все же вопрос в том, как обеспечить разделение заведомо не-злонамеренных программ, т.е. избежать отказов из-за ошибок в софте, а не намеренных диверсий.
DrPass, тем не менее, вопрос был про процессор 8086.
НЛО прилетело и опубликовало эту надпись здесь
Хотелось бы услышать предложения khim, как реализовать защиту от такого на процессоре 8086.
От чего именно вы собрались защищаться? HLT — не HCF, её, как бы, даже и разумно вызывать когда вы ждёте нажатия клавиши или таймера. Даже на 8086.

А таблицу прерываний можно защитить поставив пару триггеров между памятью и процессором.

Так что при наличии желания и достаточно «очумелых» ручек всё делается, конечно.
НЛО прилетело и опубликовало эту надпись здесь
Нет, не путаю. Первое требуется для надёжной реализации второго, но это разные вещи.

Фактически jmp . делает то же самое, что и hlt (на современных процессорах можно заметить разницу по температуре, в 80е даже этого было сделать нельзя). И при этом работает во всех, самых защищённых и современных процессорах.

Вас это не смущает?
НЛО прилетело и опубликовало эту надпись здесь
Меня смущает, вы так и не дали ответа, как пара триггеров помогут реализовать защищенный режим.
Пара триггеров нужны, чтобы защищённая часть операционки могла защитить область прерываний от пользовательской программы. Разумеется для того, чтобы реализовать защищённый режим — вам потребуется сопроцессор, но их и так для 8086 было два: 8087 и 8089.

Пример с зацикливанием jmp тоже смущает, потому что в режиме пользователя невозможно запретить прерывания и система может переключиться на другую задачу.
NMI вообще ни в каком режиме нельзя запретить. И он вас вышибет и из jmp . и из hlt.

Да, конечно, всё это требует некоторых нетривиальных манипуляций, но если люди умудрялись к 68000 реализовывать UNIX — то непонятно что может вам помешать это сделать на 8086.
НЛО прилетело и опубликовало эту надпись здесь
Сложный вопрос. Я просто объясняю, что ваше утверждение «операционки вроде DOS не делали изоляцию железа по одной простой причине — процессор это не поддерживал» является бредом.

DOS ведь появилась не на пустом месте — она разрабывалась как часть проекта по созданию IBM 5150… проекта, который маркетологи поставили в один ряд с другими компьютерами IBM 51xx. При этом, внезапно, как раз родоночальнык, IBM 5100 — эмулировал IBM/370… которая, как раз, уже поддерживала и защиту паямти и много чего ещё.

Это, кстати, другой вариант, про который я просто забыл, извините.

А на процессорах 68000, которые тоже не содержали в процессоре никакой защиты — небезизвестный Sun свои первые Unix-машинки делал.

То есть DOS не поддерживал защиту не потому, что процессор там чего-то не мог, а потому что для этого, помимо процессора 8086 требовалось добавить в систему ещё кой-какое железо (или ограничиться эмуляций — что привелобы, конечно, к ужасной скорости… но USCD p-System именно это и делала, хоть и опционально… так что такой вариант тоже рассматривался). И разработчики IBM PC — решили этого не делать. Хотя могли бы.

P.S. Между прочим когда Билл Гейтс говорил с представителями Microsoft о поставках операционки — он не блефовал… это не был «бизнес по русски» (когда один пошёл «искать вагон сахара, другой – искать деньги»). У Microsoft уже была операционка под названием MDOS или MIDAS (про неё даже Wikipedia пишет… правда почему-то в статье про её автора только). Но IBM она показалась «слишком тяжёлой» (хотя как раз туда защита подошла бы прекрасно). И многозадачаную MS-DOS — тоже IBM «зарезала» (в пользу OS/2). В общем чётко видно, что «тяжёлая» операционка с защитой — тогда в планы IBM не вписывалась… потому её и не было. А не потому что в системе на базе 8086 её было невозможно сделать…
является бредом.

Так, к слову, если какое-либо утверждение лично вам не нравится, и даже если оно объективно неверное, оно от этого бредом не становится :)
На самом деле вы все забываете, что речь идет о персональном компьютере. Это машина, которая принципиально создавалась для использования одним человеком. Создавалась в эпоху задолго до появления компьютерных вирусов и вообще зловредных программ. Поэтому при проектировании IBM PC защита памяти вообще и близко в планах не стояла, и потребности в ней даже не горизонте не просматривалось. Вот многозадачность — да, это в перспективе могло потребоваться.
Защита памяти не имеет никакой связи со зловредными программами.
Защита пямяти появилась в 1960-е, первые зловреды — в 1980-е.
Защита памяти не имеет никакой связи со зловредными программами.

На однопользовательских компьютерах имеет самое непосредственное. Если мы говорим про мейнфрейм, там изоляция страниц памяти нужна для того, чтобы данные разных пользователей не пересекались. На персоналке 1990-х это было востребовано только для того, чтобы нежелательный софт не лез в пространство других процессов, никаких других применений этому в однопользовательской среде нет.
На однопользовательских многозадачных системах она нужна затем, чтобы сбой одной программы не приводил ко крэшу всей системы.
Тем не менее, защита появилась на однопользовательских многозадачных системах тогда, когда практически во всех приложениях память распределялась достаточно надёжными программными менеджерами, и битые указатели не гуляли куда попало. Зато с завидной регулярностью выходили разного рода зловреды.
Можете объяснить, как защита памяти на однопользовательских многозадачных системах на персоналках 1990-х (т.е. в Win9x) препятствовала зловредам?
Напомню, что там любой исполняющийся код имел «права администратора».
Не могу. Но я также не смог бы и объяснить, как она там помогала защищаться от сбоев приложений, учитывая, что область системных библиотек пользовательского режима в диапазоне 2-3 Гб в Вин9х общая для всех приложений, и также доступна для записи.
На самом деле вы все забываете, что речь идет о персональном компьютере.
Я-то как раз не забываю. Но тут стрелочка в другую сторону: если мы делаем дешёвый компьютер с однозадачной системой, то нам защита, так-то, не особо и нужна. А это значит что мы возьмём процессор без защиты и ничего аппаратного туда прикручивать тоже не будем.

Но тут, как бы, причина — это персональный помпьютер, а уже следствия — «OS без излишеств» и под неё — процессор без MMU.

Так, к слову, если какое-либо утверждение лично вам не нравится, и даже если оно объективно неверное, оно от этого бредом не становится :)
Согласен. Бредом оно становится потому что человек путает причину со следствием, а не потому что оно неверное.
НЛО прилетело и опубликовало эту надпись здесь
тем не менее, вопрос был про процессор 8086.

Я имел в виду существующие архитектуры персональных компьютеров, в смысле, реализация защиты на стороне софта, без изменения схемы персональных ПК.
Без железа, конечно, на 8086 никакой защиты нету. Но можно придумать относительно недорогую схему, позволяющую создавать защищённые OS с разделяемыми программами.

Не Unix, конечно, там полноценное MMU нужно. Но что-то похожее на ранние операционки на PDP-11 — легко.

Вопрос в размерах. В 16K вы это вот всё — точно не упихате. И даже в 64K (минимальный объём для реальной работы PC-DOS, вроде бы).
Вопрос подразумевал, как это сделать на существующих архитектурах. Понятное дело, что со «внешним аппаратным чем-то» можно сколь угодно фич реализовать. Так-то и в советской ЕС 1842 добавили к 8086, пардон, 1810ВМ86 защищённый режим с помощью дополнительной микросхемы-менеджера памяти. Впрочем, 1810ВМ86 там тоже был несколько напильником обработан, получив такую волшебную фичу 286-го, как Invalid opcode interrupt
Боюсь, что в 1978 году 640К это было очень много и стоили они сотни долларов.
640K? Сотни долларов? Где вы нашли такую дешёвую память?

Сюда гляньте.

Закон Мура — это когда вперёд смотреть хорошо. А как в прошлое глянешь — так от цен волосы начинают шевелиться там, где им и расти-то не положено…
Да, 20-битного адреса в 1978 году было более чем достаточно. Но вот 16-битного — уже нет, пришлось городить сдвинутые на 4 бита сегментные регистры. Это создавало проблемы при работе с данными размером больше 64К, которые были очевидны уже в 1978 году. Избавить от этих проблем могли бы 32-разрядные регистры адреса.
Сначала хватило бы и 24-битных. Так и появился 286 (к тому же, который мог 1 ГБ виртуальной памяти адресовать).

Особенно части ALU реализуюище умножение и деление — совсем чуть-чуть увеличаться в обьеме. /s.


P.S. Одна из "фишек" 8086 (и 8088) была в том, что его запихали в 40-пиновый стандартный корпус. Не помню всех подробностей, но производителям это оказалось удобно в тот момент.
Как результат — у 40-ножной микросхемы даже при 20-битной шине адреса и 16 битной шине данных — не хватило на все ног, так что пришлось делать шину данных и адреса мультиплексирующими, т.е. одни и те-же ноги использовались как для данных так и для адреса, в зависимости от управляющих сигналов на других ногах.
Представьте как вы бы 32х битную шину адреса и 32х битную шину данных в это запихивали. Даже при условии полной мулттиплексии на все остальное оставалось бы 8 ног, из которых как минимум 2 — питание.


P.S. А в фотографии процессора со вскрытой крышкой завораживает тот факт, что в принципе вооружившись хорошей лупой и иголкой, можно взять и "ткнуть иголкой в регистр AX", т.е. все структуры процессора более менее видны не очень вооруженным глазом.

Особенно части ALU реализуюище умножение и деление — совсем чуть-чуть увеличаться в обьеме. /s
Они увеличатся и сильно и чуть-чуть и даже уменьшатся. Всё одновременно. Ну просто потому что любое утверждение, касающееся элементов пустого множества — истинно.

Представьте как вы бы 32х битную шину адреса и 32х битную шину данных в это запихивали.
А зачем это представлять? У 80386SX, думаете, шина адреса 32-битная? Ага, щаз. И шина адреса и шина данных уже, чем 32-бита.

Так что нет — сделать процессор 32-битным было возможно. 68000 вышел всего через год после 8086. Просто, в те времена, это не казалось очень нужным… а главное — 32бита были «зарезервированы» под 8800 iAPX432. Вот когда он вышел и умер — начали делать первый нормальный процессор на базе 8086…
Особенно части ALU реализуюище умножение и деление — совсем чуть-чуть увеличаться в обьеме.
Там нет аппаратного умножения и деления — только микропрограммное. Соответственно, если и есть какие-то аппаратные блоки для этого — то это всего лишь счётчик битов, не более того. Его разрядность увеличится с 4 до 5 бит. А корпус и шину можно было оставить без изменений. Хотя, конечно, это тормозило систему — но по-видимому так было существенно дешевле.

Ну как минимум сумматор то там был? без него умножение занимало бы не 40-50 тактов, а все 500-1000.
А даже сумматор, если сделать хотя бы частичный carry-lookahead — уже довольно много места занимает. (И при удвоении разрядности будет как минимум в двое больше занимать, либо будет больше тормозить)

Ну да, АЛУ при увеличениии разрядности вдвое будет занимать примерно вдвое больше места. Но это учтено в моей оценке увеличения площади кристалла на 15..20%. Схема быстрого переноса при увеличении разрядности растёт больше чем вдвое, но это превышение мало по сравнению со всей схемой сумматора.
Интересно, когда на Ютюбе появятся видосы энтузиастов «Как сделать процессор 486 в домашних условиях»? Просто для сравнения люди создают точнейшие чпу станки в кустарных условиях, проводят сложные химические реакции в простых лабораториях гаражного уровня, насколько литографический процесс стал ближе за эти годы к самоделкиным?
Не нашел Bill of materials
Altera или xilinx 100+ klut.это где то от $100 и больше
Ну это же не изготовление процессора ни разу. Это просто эмулятор. Вы можете 486-й эмулировать и без всяких ПЛИСок. Тут речь же идет про кустарное производство микросхем, а 486-й процессор просто как пример с долей иронии привели.
Неа. Это не эмулятор. Это попытка реконструкции. Ее можно залить в ASIC.К примеру если интель опубликует полную начинку, то можно её залить как есть.
Ее можно залить в ASIC.

Как_нарисовать_сову.jpeg
Ну примерно… Но назвать эту работу (ao486) просто эмуляцией, будет еще дальше от истины.
Я не считаю ao486 эмуляцией; я считаю эту работу — применительно к созданию клона 486 у себя в гараже — двумя кружочками от совы.
Это всё-таки не то: статья про то, что «большие дяди» готовы принимать проекты и бесплатно их реализовывать мелкими партиями, а вопрос был про «сделать дома», как сейчас делают печатные платы под очень мелкие детали, которые раньше были доступны только этим самым «большим дядям».
насколько литографический процесс стал ближе за эти годы к самоделкиным?

Пока ни на сколько, всё-таки оборудование сложное и дорогое нужно. Тут где-то была статья, как молодой парень сделал в гараже микросхему, но там за кадром остался момент, как папа этого парня вложил сотню тысяч долларов в покупку оборудования. В общем, хобби для больших энтузиастов.
насколько литографический процесс стал ближе за эти годы к самоделкиным?

У BarsMonster был тут когда то написан цикл статей
habr.com/ru/post/118534
habr.com/ru/post/145373
habr.com/ru/post/188992
Ответ на вопрос — процесс ближе к самоделкам особо не стал, т.к. в одну каску — фатально много времени нужно. Это же и меня срезало.

В мире есть наверное с десяток людей, которые домашние микросхемы делали в одиночку, или самые их критичные элементы. Но больше 10 транзисторов у самодельщиков не видел.

Так что о 486 дома думать не стоит…

Я все жду когда появится энтуазист делающий современные платы (и мосты) под супер 7, с AGP 2x, PCI и USB 2.0, еще и в формате малинки. Может доживу до этих дней и достану сейвы старых игр с винчестера и наконец допройду Героев :D

НЛО прилетело и опубликовало эту надпись здесь
Обиднее всего, что он не взлетел из-за классического синдрома второй системы: в него попытались запихать сразу, одновременно, слишком много всего — в результате получился монстр, который просто было невозможно «испечь» на техпроцессах того времени. Intel попыталась даже исправить ошибки… но время было упущено. Максимум для чего вся эта чудесная машинерия использовалась массово — XOR-сопроцессор для RAID-контроллеров. Чистое забивание гвоздей микроскопом.
Зачем рендер процессора на первой фотке? Он не соответствует оригиналу.
В оригинале его нет, так что это прихоть переводчика.
8086 совсем не совместим с 8080, ни бинарно, ни по ассемблеру. Надо вручную команды переделывать, ну может только немного автоматизировать трансляцию. Иначе CP/M под 8086 быстрей вышла.
Надо вручную команды переделывать, ну может только немного автоматизировать трансляцию

Ну чего «немного»? Оно полностью автоматизируется, программа 8080 по адресам отлично укладывается в сегмент 8086, а команды мапятся один к одному. Так же и задумывалось изначально.
Иначе CP/M под 8086 быстрей вышла.

Портирование операционки — это не только про трансляцию процессорного кода. Это ещё и адаптация под конкретный компьютер, под его функции BIOS, под его распределение памяти и портов ввода/вывода, под системы команд его устройств.
Просто я хотел сказать что сам синтаксис ассемблера 8080 и 8086 довольно сильно различаются, так что просто так перекомпилировать исходник не получится. Надо сначала надо воспользоватся транслятором 8080to8086, а потом ассемблером 8086, при этом могут быть ошибки, скорей всего понабиться хоть немного ручной работы. А вообще лучше вручную переделать программу с учётом новых возможностей 8086.
А так, транслятором можно и например 6502 в 8086 транслировать, так что это не в счёт.
Кстати, можно какой нибудь ассемблер, например UASM дополнить генерации кода для 8080, Z80 под Intel8086 стиль команд.
Типа так: mov A,[HL], add A, B. И так далее. Тогда можно говорить о некоторой совместимости на уровне ассемблера.
Надо сначала надо воспользоватся транслятором 8080to8086, а потом ассемблером 8086, при этом могут быть ошибки, скорей всего понабиться хоть немного ручной работы. А вообще лучше вручную переделать программу с учётом новых возможностей 8086.

Вы всерьёз полагаете, что при переписывании программы вручную ошибок будет меньше, чем при автоматической трансляции?

А так, транслятором можно и например 6502 в 8086 транслировать, так что это не в счёт.

Можете назвать хоть один транслятор 6502 в 8086, существовавший в 1980-х?

При этом транслятор 8080 в 8086 реально существовал, он разрабатывался Intel параллельно с разработкой 8086, и система команд 8086 намеренно составлялась так, чтобы такую трансляцию упростить.
В исходниках MSDOS лежит файлик с вот таким именем
TRANS.ASM
; Z80 to 8086 Translator version 2.21
; Runs on the 8086 under 86-DOS
; by Tim Paterson

;
ORG 100H
EOF: EQU 1AH ;End of file
EOL: EQU 0DH
FCB: EQU 5CH
SYSTEM: EQU 5
OPEN: EQU 15
CLOSE: EQU 16
SETDMA: EQU 26
CREATE: EQU 22
DELETE: EQU 19
READ: EQU 20
WRITE: EQU 21
PRNBUF: EQU 9
MOV SP,STACK
MOV DX,HEADER
MOV CL,9
CALL SYSTEM
MOV BX,FCB+12
XOR AL,AL
MOV CH,4
CLRFCB:
MOV [BX],AL
INC BX
DEC CH
JNZ CLRFCB
MOV [FCB+32],AL
MOV BX,FCB
MOV DX,PUTFCB
MOV CX,16
UP
MOV SI,BX
MOV DI,DX
REP
MOVB
MOV DX,DI
MOV BX,SI
MOV [PUTFCB+32],AL
MOV BX,«A»+5300H ;«AS»
MOV [PUTFCB+9],BX
MOV AL,'M'
MOV [PUTFCB+11],AL
MOV DX,FCB
MOV CL,OPEN
CALL SYSTEM
INC AL
MOV DX,NOFILE
JZ ABORTJ
MOV DX,PUTFCB
MOV CL,DELETE
CALL SYSTEM
MOV DX,PUTFCB
MOV CL,CREATE
CALL SYSTEM
INC AL
MOV DX,NOROOM
ABORTJ:
JZ ABORT
MOV DX,PUTFCB
MOV CL,OPEN
CALL SYSTEM
MOV BX,PUTBUF
MOV [PUTPT],BX
MOV BX,GETBUF+80H
MOV [GETPT],BX
TRANLN:
XOR AL,AL
MOV [OP1],AL
MOV [OP2],AL
MOV BX,OPCODE
CALL LOAD
MOV BX,OP1
CALL GETOP
MOV B,[BX],0
MOV BX,OP2
CALL GETOP
DOLIN:
MOV B,[BX],0
CALL FINDOP
ENLIN:
MOV SP,STACK
MOV AL,[CHAR]
CMP AL,';'
JNZ NOCOM
MOV AL,9
CALL PUTCH
MOV AL,';'
NOCOM:
CALL PUTCH
PUTLIN:
CMP AL,EOF
JZ END
CALL GETCH
CALL PUTCH
CMP AL,10
JNZ PUTLIN
JP TRANLN
END:
MOV CH,127
MOV AL,1AH
FILL:
CALL PUTCH
DEC CH
JNZ FILL
MOV DX,PUTFCB
MOV CL,CLOSE
CALL SYSTEM
MOV DX,ENDMES
ABORT:
MOV CL,PRNBUF
CALL SYSTEM
JMP 0
DELIM:
CALL GETCH
DELCHK:
CMP AL,EOL
JZ DOLIN
CMP AL,EOF
JZ DOLIN
CMP AL,';'
JZ DOLIN
CMP AL,' '
JZ RET
CMP AL,':'
JZ RET
CMP AL,','
JZ RET
CMP AL,9
RET
HEX:
AND AL,0FH
ADD AL,90H
DAA
ADC AL,40H
DAA
PUTCH:
PUSH BX
PUSH DX
PUSH CX
LAHF
XCHG AH,AL
PUSH AX
XCHG AH,AL
AND AL,7FH
MOV BX,[PUTPT]
MOV [BX],AL
INC BX
MOV [PUTPT],BX
CMP BX,PUTBUF+80H
JNZ POPRET
MOV DX,PUTBUF
MOV [PUTPT],DX
MOV CL,SETDMA
CALL SYSTEM
MOV DX,PUTFCB
MOV CL,WRITE
CALL SYSTEM
OR AL,AL
MOV DX,WRTERR
JNZ ABORT
POPRET:
POP AX
XCHG AH,AL
SAHF
NOTAF:
POP CX
POP DX
POP BX
RET
;
; Get character from source file.
;
GETCH:
PUSH BX
PUSH DX
PUSH CX
MOV BX,[GETPT]; Get buffer pointer.
CMP BX,GETBUF+80H; Past end-of-buffer?
JNZ GETIT; Jump if not.
MOV DX,GETBUF; Set `DMA address'.
MOV CL,SETDMA
CALL SYSTEM
MOV DX,FCB; Read the next record from source file.
MOV CL,READ
CALL SYSTEM
CMP AL,0; Entire record read OK?
JE OKRECORD
CMP AL,3; Partial record read?
JE OKRECORD
MOV AL,EOF; Force end-of-file character in case
JP TESEND; there is nothing in the record.
OKRECORD:
MOV BX,GETBUF; Reset buffer pointer.
GETIT:
MOV AL,[BX]; Get next character from buffer.
INC BX; Point to next character.
MOV [GETPT],BX; Save new pointer.
TESEND:
MOV [CHAR],AL
JP NOTAF; Pop registers and return.
LOAD:
CALL DELIM
JZ LOADOP
EATLAB:
CALL PUTCH
CALL DELIM
JNZ EATLAB
ENLAB:
MOV AL,':'
CALL PUTCH
LOADOP:
MOV BX,OPCODE
EATEM:
CALL DELIM
JZ EATEM
LOADLP:
CALL IDCHK
JNC $+5
JMP OPERR
MOV [BX],AL
INC BX
CALL DELIM
JNZ LOADLP
MOV B,[BX],0
CMP AL,':'
JNZ RET
MOV BX,OPCODE
CALL TRANS
JP ENLAB
GETOP:
XOR AL,AL
LAHF
XCHG AX,BP
SAHF
GETLP:
CALL DELIM
JZ GETLP
OPCHAR:
CMP AL,'('
JNZ NOTLEF
LAHF
XCHG AX,BP
SAHF
INC AL
LAHF
XCHG AX,BP
SAHF
MOV B,[BX],'['
JP NEXCH
NOTLEF:
CMP AL,')'
JNZ NOTRIT
LAHF
XCHG AX,BP
SAHF
DEC AL
LAHF
XCHG AX,BP
SAHF
MOV B,[BX],']'
JP NEXCH
NOTRIT:
MOV [BX],AL
CMP AL,''''
JZ EATQUO
CALL IDCHK
JNC GETID
NEXCH:
INC BX
CALL GETCH
IDRET:
CALL DELCHK
JNZ OPCHAR
CMP AL,' '
JZ OPCHAR
RET
EATQUO:
INC BX
CALL GETCH
MOV [BX],AL
CMP AL,';'
JZ L0000
CALL DELCHK
L0000:
CMP AL,''''
JNZ EATQUO
JP NEXCH
IDCHK:
CMP AL,'0'
JC RET
CMP AL,'9'+1
CMC
JNC RET
CMP AL,40H
JC RET
AND AL,5FH
CMP AL,'A'
JC RET
CMP AL,'Z'+1
CMC
RET
GETID:
MOV [BX],AL
MOV CH,1
LODID:
INC BX
CALL GETCH
CALL IDCHK
JC RWCHK
MOV [BX],AL
INC CH
JP LODID
RWCHK:
LAHF
XCHG AH,AL
PUSH AX
XCHG AH,AL
PUSH BX
DEC BX
DEC CH
MOV DL,CH
JZ LOOKRW
MOV DL,[BX]
DEC BX
DEC CH
JNZ NORW
LOOKRW:
MOV AL,[BX]
MOV DH,AL
PUSH BX
MOV BX,RWTAB
MOV CX,LENRW
RWLK:
UP
MOV DI,BX
REPNZ
SCAB
MOV BX,DI
JNZ NOTRW
PUSH BX
PUSH CX
MOV CX,LENRW-1
LAHF
ADD BX,CX
RCR SI
SAHF
RCL SI
MOV AL,[BX]
POP CX
POP BX
CMP AL,DL
JZ HAVRW
MOV AL,CL
OR AL,AL
MOV AL,DH
JNZ RWLK
NOTRW:
POP BX
NORW:
POP BX
ENDRW:
POP AX
XCHG AH,AL
SAHF
JMP IDRET
HAVRW:
POP BX
INC CL
MOV [BX],CL
INC BX
POP DX
PUSH BX
MOV AL,CL
MOV BX,IXSI
CMP AL,RSI
JZ IXIY
MOV BX,IYDI
CMP AL,RDI
JNZ NORW
IXIY:
LAHF
XCHG AX,BP
SAHF
JZ NOTENC
LAHF
XCHG AX,BP
SAHF
CALL OUTSTR
JP NORW
NOTENC:
LAHF
XCHG AX,BP
SAHF
POP BX
DEC BX
MOV B,[BX],'['
INC BX
ADD AL,RIX-1
MOV [BX],AL
INC BX
MOV B,[BX],']'
INC BX
JP ENDRW
RET
FINDOP:
MOV BX,OPCODE
MOV CX,5
XOR AL,AL
UP
MOV DI,BX
REPNZ
SCAB
MOV BX,DI
JNZ OPERR
MOV AL,4
SUB AL,CL
JZ RET
DEC AL
JZ OPERR
MOV CL,AL
DEC BX
DEC BX
OR B,[BX],080H
MOV AL,[OPCODE]
SUB AL,'A'
JC OPERR
ADD AL,AL
MOV DL,AL
MOV DH,0
MOV BX,OPTAB
LAHF
ADD BX,DX
RCR SI
SAHF
RCL SI
MOV DL,[BX]
INC BX
MOV DH,[BX]
XCHG DX,BX
MOV AL,9
CALL PUTCH
LOOKOP:
MOV AL,[BX]
OR AL,AL
JZ OPERR
MOV DX,OPCODE+1
MOV CH,CL
LOOKLP:
MOV SI,DX
LODB
CMP AL,[BX]
JNZ NEXOP
INC DX
INC BX
DEC CH
JNZ LOOKLP
MOV DX,[BX]
MOV BX,[BX+2]
JMP DX
NEXOP:
RCR SI
TEST B,[BX],080H
RCL SI
LAHF
INC BX
SAHF
JZ NEXOP
MOV DX,4
LAHF
ADD BX,DX
RCR SI
SAHF
RCL SI
JP LOOKOP
OPERR:
MOV BX,OPCODE
CALL OUTSTR
CALL TWOOPS
MOV BX,OPCDER
CALL OUTSTR
JMP ENLIN
LD:
CALL OUTSTR
MOV BX,OP1
MOV DX,OP2+1
CALL LCHECK
JNZ $+5
JMP LDAX
XCHG DX,BX
DEC BX
INC DX
CALL LCHECK
JNZ $+5
JMP STAX
;If immediate move, check for byte memory reference
MOV AL,[OP2]
CMP AL,20H ;Could be immediate?
MOV AL,9
JC L0001
CALL BYTCHK ;Add «B,» if memory reference
L0001:
CALL TRAN1
JP TRNOP2
TWOOPS:
CALL TRNOP1
TRNOP2:
MOV AL,','
TRAN2:
MOV BX,OP2
PTRANS:
CALL PUTCH
TRANS:
MOV AL,[BX]
LAHF
INC BX
SAHF
OR AL,AL
JZ RET
CALL TRNTOK
JP TRANS
LCHECK:
MOV AL,[BX]
CMP AL,RAL
JNZ RET
MOV SI,DX
LODB
CMP AL,RCX
JZ RET
CMP AL,RDX
RET

ONEOP:
CALL OUTSTR
MOV AL,9
CALL BYTCHK ;If memory reference, add «B,» flag
JMPS TRAN1

TRNOP1:
MOV AL,9
TRAN1:
MOV BX,OP1
JP PTRANS
IN:
MOV AL,[OP1]
CMP AL,RAL
XCHG DX,BX
MOV BX,OP2
JZ GETPORT
MOV BX,SAVEAX
CALL OUTSTR
CALL OUTSTR
MOV BX,OP2
CALL GETPORT
MOV BX,MOV0
CALL ONEOP
MOV AL,','
CALL PUTCH
MOV AL,RAL
CALL TRNTOK
IODONE:
MOV BX,RESTAX
JMP OUTSTR
OUT:
MOV AL,[OP2]
XCHG DX,BX
MOV BX,OP1
CMP AL,RAL
JZ GETOUT
MOV BX,SAVEAX
CALL OUTSTR
MOV BX,MOVAL
CALL OUTSTR
CALL TRNOP2
MOV BX,CRLFTB
CALL OUTSTR
MOV BX,OP1
CALL GETOUT
JP IODONE
GETPORT:
MOV AL,[BX]
CMP AL,'['
JNZ NOBRAK
LAHF
INC BX
SAHF
PUSH BX
MOV CX,80
MOV AL,']'
UP
MOV DI,BX
REPNZ
SCAB
MOV BX,DI
LAHF
DEC BX
SAHF
MOV B,[BX],0
POP BX
NOBRAK:
MOV AL,[BX]
CMP AL,RGCL
JNZ FIXPOR
MOV BX,IO1
CALL OUTSTR
XCHG DX,BX
CALL OUTSTR
MOV AL,RDX
CALL TRNTOK
MOV BX,IO2
JMP OUTSTR
GETOUT:
CALL GETPORT
JNC RET
MOV BX,BADIO
JMP OUTSTR
FIXPOR:
XCHG DX,BX
CALL OUTSTR
XCHG DX,BX
JMP TRANS
LDAX:
MOV BX,LDAX1
LSAX:
CALL OUTSTR
MOV SI,DX
LODB
CALL TRNTOK
JP OUTSTR
STAX:
MOV BX,STAX1
JP LSAX
TRNTOK:
CMP AL,' '
JC $+5
JMP PUTCH
PUSH BX
PUSH CX
MOV CL,AL
MOV CH,0
MOV BX,TOKTAB-2
LAHF
ADD BX,CX
RCR SI
SAHF
RCL SI
LAHF
ADD BX,CX
RCR SI
SAHF
RCL SI
MOV AL,[BX]
CALL PUTCH
INC BX
MOV AL,[BX]
POP CX
POP BX
OR AL,AL
JZ RET
JMP PUTCH
PUSH:
MOV DX,PUSHAF
JP AFCHK
POP:
MOV DX,POPAF
AFCHK:
MOV AL,[OP1]
CMP AL,RAX
JNZ ONEOPJ
XCHG DX,BX
OUTSTR:
MOV AL,[BX]
OR AL,AL
JNZ L0002
CALL NEWOP
L0002:
CALL PUTCH
INC BX
ADD AL,AL
JNC OUTSTR
RET
NEWOP:
MOV AL,13
CALL PUTCH
MOV AL,10
CALL PUTCH
MOV AL,9
RET
LDDR:
CALL OUTSTR
MOV BX,BLMOVE
JP OUTSTR
CPDR:
CALL OUTSTR
MOV BX,CMPREP
JP OUTSTR
ADD:
MOV AL,[OP1]
CMP AL,RBX
JZ DAD
ARITH:
CALL OUTSTR
MOV AL,[OP2]
OR AL,AL
JZ $+5
JMP TWOOPS
MOV AL,9
CALL PUTCH
MOV AL,RAL
CALL TRNTOK
MOV AL,','
JMP TRAN1
ACCUM:
CALL OUTSTR
MOV AL,9
CALL PUTCH
MOV AL,RAL
JMP TRNTOK
ONEOPJ: JMP ONEOP
DAD:
MOV BX,DAD1
CALL OUTSTR
CALL TWOOPS
MOV BX,DAD2
JP OUTSTR

INCDEC:
MOV AL,[OP1]
CMP AL,RCX+1 ;16-bit?
JNC ONEOPJ
MOV BX,LAHF
CALL OUTSTR
XCHG DX,BX
MOV BX,OPCODE-1
CALL ONEOP
XCHG DX,BX
OUTSTRJ:
JMP OUTSTR
JUMP:
MOV AL,[OP1]
CMP AL,'['
JNZ DIRECT
MOV AL,[OP1+1]
MOV [OP1],AL
XOR AL,AL
MOV [OP1+1],AL
DIRECT:
MOV AL,[OP2]
OR AL,AL
JZ ONEOPJ
CALL FIXCON
MOV BX,OP2
OUTCON:
MOV CH,AL
MOV AL,'J'
CALL PUTCH
MOV AL,CH
CALL TRNTOK
MOV AL,9
CALL PTRANS
MOV AL,CH
CMP AL,ODDPAR
MOV BX,WARNPA
JZ OUTSTRJ
CMP AL,EVEPAR
JZ OUTSTRJ
RET
FIXCON:
MOV AL,[OP1]
CMP AL,RGCL
JNZ RET
MOV AL,CY
RET
RETURN:
MOV AL,[OP1]
OR AL,AL
JZ OUTSTRJ
MOV BX,'R'+4500H ;«RE»
MOV [OP2],BX
MOV BX,'T'
MOV [OP2+2],BX
JP DIRECT
ONEOPJ1:
JMP ONEOP
DOCALL:
MOV AL,[OP2]
OR AL,AL
JZ ONEOPJ1
CALL FIXCON
DEC AL
XOR AL,1
INC AL
MOV BX,LABEL
CALL OUTCON
MOV BX,OPCODE-1
CALL OUTSTR
MOV AL,[OP2]
OR AL,AL
MOV AL,9
MOV BX,OP2
JZ L0003
CALL PTRANS
L0003:
MOV BX,CRLF
CALL OUTSTR
CALL TRANS
CALL OUTSTR
MOV BX,LABEL+4
NEXLAB:
INC [BX]
MOV AL,[BX]
CMP AL,'9'+1
JNZ RET
MOV B,[BX],'0'
LAHF
DEC BX
SAHF
JP NEXLAB
EX:
MOV AL,[OP1]
CMP AL,RAX
JZ OUTSTRJ1
MOV AL,[OP1+1]
CMP AL,STP
JZ XTHL
MOV BX,XCHG
CALL OUTSTR
JMP TWOOPS
XTHL:
MOV BX,XTHL1
CALL OUTSTR
CALL TRNOP2
MOV BX,XTHL2
OUTSTRJ1:
JMP OUTSTR
PSEUDO:
CALL ONEOP
MOV AL,[OP2]
OR AL,AL
JZ RET
JMP TRNOP2
RET
BITSET:
MOV CL,0
JP SETRES
RES:
MOV CL,-1
SETRES:
CALL OUTSTR
PUSH BX
MOV AL,[OP2]
CMP AL,'['
MOV AL,9
JNZ L0004
CALL BFLAG
L0004:
CALL TRAN2
MOV AL,','
CALL PUTCH
CALL GETBIT
MOV BX,BITERR
JNC L0005
CALL OUTSTR
L0005:
POP BX
JMP OUTSTR

BYTCHK:
;Check if memory reference and add «B,» for byte mode
CMP B,[OP1],"[" ;Memory reference?
JNZ RET
CMP B,[OP1+1],RIX ;Referencing IX as a word?
JZ RET
CMP B,[OP1+1],RIY
JZ RET
BFLAG:
CALL PUTCH
MOV AL,'B'
CALL PUTCH
MOV AL,','
RET

GETBIT:
MOV AL,[OP1+1]
OR AL,AL
STC
JNZ RET
MOV AL,[OP1]
SUB AL,'0'
JC RET
CMP AL,8
CMC
JC RET
MOV CH,AL
INC CH
XOR AL,AL
STC
SHFT:
RCL AL
DEC CH
JNZ SHFT
XOR AL,CL
MOV CH,AL
MOV AL,'0'
CALL PUTCH
MOV AL,CH
RCR AL
RCR AL
RCR AL
RCR AL
CALL HEX
MOV AL,CH
CALL HEX
MOV AL,'H'
JMP PUTCH
OPTAB:
DW AOPS,BOPS,COPS,DOPS,EOPS
DW FOPS,GOPS,HOPS,IOPS,JOPS
DW KOPS,LOPS,MOPS,NOPS,OOPS
DW POPS,QOPS,ROPS,SOPS,TOPS
DW UOPS,VOPS,WOPS,XOPS,YOPS
DW ZOPS
AOPS:
DM 'DD'
DW ADD,OPCODE
DM 'DC'
DW ARITH,OPCODE
DM 'ND'
DW ARITH,OPCODE
DB 0
BOPS:
DM 'IT'
DW BITSET,TESBIT
DB 0
COPS:
DM 'ALL'
DW DOCALL,OPCODE
DM 'P'
DW ARITH,CMP
DM 'PL'
DW ACCUM,NOT
DM 'PIR'
DW OUTSTR,CPIR
DM 'PDR'
DW CPDR,DOWN
DM 'CF'
DW OUTSTR,CMC
DB 0
DOPS:
DM 'EC'
DW INCDEC,OPCODE
DM 'JNZ'
DW ONEOP,DJNZ
DM 'AA'
DW OUTSTR,OPCODE
DM 'I'
DW OUTSTR,OPCODE
DM 'W'
DW PSEUDO,OPCODE
DM 'B'
DW PSEUDO,OPCODE
DM 'M'
DW PSEUDO,OPCODE
DM 'S'
DW ONEOP,OPCODE
DB 0
EOPS:
DM 'X'
DW EX,EXAF
DM 'I'
DW OUTSTR,OPCODE
DM 'XX'
DW OUTSTR,EXX
DM 'QU'
DW ONEOP,OPCODE
DM 'NDIF'
DW OUTSTR,OPCODE
DB 0
FOPS:
DB 0
GOPS:
DB 0
HOPS:
DM 'ALT'
DW OUTSTR,HLT
DB 0
IOPS:
DM 'NC'
DW INCDEC,OPCODE
DM 'N'
DW IN,INB
DM 'F'
DW ONEOP,OPCODE
DB 0
JOPS:
DM 'R'
DW JUMP,JR
DM 'P'
DW JUMP,JMP
DB 0
KOPS:
DB 0
LOPS:
DM 'D'
DW LD,MOV
DM 'DIR'
DW OUTSTR,UP
DM 'DDR'
DW LDDR,DOWN
DB 0
MOPS:
DB 0
NOPS:
DM 'EG'
DW ACCUM,OPCODE
DB 0
OOPS:
DM 'R'
DW ARITH,OPCODE
DM 'UT'
DW OUT,OUTB
DM 'RG'
DW ONEOP,OPCODE
DB 0
POPS:
DM 'OP'
DW POP,OPCODE
DM 'USH'
DW PUSH,OPCODE
DB 0
QOPS:
DB 0
ROPS:
DM 'ET'
DW RETURN,OPCODE
DM 'LA'
DW ACCUM,RCL
DM 'RA'
DW ACCUM,RCR
DM 'LCA'
DW ACCUM,ROL
DM 'RCA'
DW ACCUM,ROR
DM 'L'
DW ONEOP,RCL
DM 'R'
DW ONEOP,RCR
DM 'LC'
DW ONEOP,ROL
DM 'RC'
DW ONEOP,ROR
DM 'ES'
DW RES,RESBIT
DM 'ETI'
DW OUTSTR,IRET
DM 'ETN'
DW OUTSTR,IRET
DM 'ST'
DW ONEOP,CALL
DB 0
SOPS:
DM 'UB'
DW ARITH,OPCODE
DM 'BC'
DW ARITH,SBB
DM 'LA'
DW ONEOP,SAL
DM 'RA'
DW ONEOP,SAR
DM 'RL'
DW ONEOP,SHR
DM 'CF'
DW OUTSTR,STC
DM 'ET'
DW BITSET,SETBIT
DB 0
TOPS:
DB 0
UOPS:
DB 0
VOPS:
DB 0
WOPS:
DB 0
XOPS:
DM 'OR'
DW ARITH,OPCODE
DB 0
YOPS:
DB 0
ZOPS:
DB 0
LDAX1: DM 9,'SI,'
DM 0,'LODB'
STAX1: DM 9,'DI,'
DM 0,'STOB'
PUSHAF: DB 'LAHF',0,'XCHG',9,'AH,AL',0,'PUSH',9,'AX',0
DM 'XCHG',9,'AH,AL'
POPAF: DM 'POP',9,'AX',0,'XCHG',9,'AH,AL',0,'SAHF'
DOWN: DM 'DOWN'
UP: DB 'UP'
BLMOVE: DB 0,'MOV',9,'SI,BX',0,'MOV',9,'DI,DX'
DB 0,'REP',0,'MOVB',0,'MOV',9,'DX,DI'
DM 0,'MOV',9,'BX,SI'
CPIR: DB 'UP'
CMPREP: DB 0,'MOV',9,'DI,BX',0,'REPNZ',0,'SCAB'
DM 0,'MOV',9,'BX,DI'
DAD1: DM 'LAHF',0,'ADD'
DAD2: DM 0,'RCR',9,'SI',0,'SAHF',0,'RCL',9,'SI'
LAHF: DM 'LAHF'
DM 0,'SAHF'
DJNZ: DB 'DEC',9,'CH',13,10
DB '; *** WARNING: DJNZ does not affect flags — DEC does.',0
DM 'JNZ'
WARNPA: DM 13,10,'; *** WARNING: Parity flag not always same as Z80.'
IO1: DB 'MOV',9,'DI,DX',0,'MOV',9,'DL,CL',0
DM 'XOR',9,'DH,DH',13,10,9
IO2: DM 0,'MOV',9,'DX,DI'
BADIO: DM 13,10,'; *** WARNING: Flags not same as Z80.'
BITERR: DM 13,10,' *** ERROR: Cannot determine bit number.'
SETBIT: DM 'LAHF',0,'OR'
DM 0,'SAHF'
RESBIT: DM 'LAHF',0,'AND'
DM 0,'SAHF'
TESBIT: DM 'RCR',9,'AH',0,'TEST'
DM 0,'RCL',9,'AH'
XTHL1: DM 'POP',9,'SI',0,'XCHG',9,'SI'
XTHL2: DM 0,'PUSH',9,'SI'
EXX: DB 'XCHG',9,'BX,[HL]',0,'XCHG',9,'DX,[DE]',0
DM 'XCHG',9,'CX,[BC]'
EXAF: DM 'LAHF',0,'XCHG',9,'AX,BP',0,'SAHF'
MOVAL: DM 0,'MOV',9,'AL'
IXSI: DM 9,'MOV',9,'SI,[IX]',13,10
IYDI: DM 9,'MOV',9,'DI,[IY]',13,10
RESTAX: DB 0
SAVEAX: DM 'XCHG',9,'AX,SI'
CRLFTB: DM 13,10,9
INB: DM 'INB',9
OUTB: DM 'OUTB',9
XCHG: DM 'XCHG'
JMP: DM 'JMP'
JR: DM 'JMPS'
RCL: DM 'RCL'
RCR: DM 'RCR'
ROL: DM 'ROL'
ROR: DM 'ROR'
SAL: DM 'SAL'
SAR: DM 'SAR'
SHR: DM 'SHR'
STC: DM 'STC'
IRET: DM 'IRET'
HLT: DM 'HLT'
CMC: DM 'CMC'
NOT: DM 'NOT'
MOV0: DB 0
MOV: DM 'MOV'
CMP: DM 'CMP'
SBB: DM 'SBB'
CALL: DM 'CALL'
TOKTAB:
DB 'SIDI'
DB 'PEPOS',0,'NSNZZ',0,'NCC',0
DB 'AXSPBXDXCX'
DB 'BLBHDLDHCLCHALIXIY'
RWTAB:
DB 'ABCDEHLBDHSACNZNPMPPII'
LENRW: EQU $-RWTAB
DB 0,0,0,0,0,0,0,'CELPF',0,'C',0,'Z',0,0,'OEYX'
HEADER: DB 13,10,'Z80 to 8086 Translator version 2.21',13,10,'$'
NOROOM: DB 13,10,'File creation error',13,10,'$'
NOFILE: DB 13,10,'File not found',13,10,'$'
ENDMES: DB 13,10,'Translation complete',13,10,'$'
WRTERR: DB 13,10,'Out of disk space',13,10,'$'
OPCDER: DM 13,10,'*** Opcode Error '
CRLF: DM 13,10
LABEL: DB 'L0000',0
DM ':',9
PUTPT: DS 2
GETPT: DS 2
CHAR: DS 1
DB 0
OPCODE: DS 80
OP1: DS 80
OP2: DS 80
PUTBUF: DS 128
GETBUF: DS 128
PUTFCB: DS 33
DS 50
STACK: EQU $
ORG 1 ;This is really just for equates without EQU
RSI: DS 1
RDI: DS 1
ODDPAR: DS 1
EVEPAR: DS 1
DS 5 ;MINUS,PLUS,NOT ZERO,ZERO,NOT CARRY
CY: DS 1
RAX: DS 1
STP: DS 1
RBX: DS 1
RDX: DS 1
RCX: DS 1
RBL: DS 1
RBH: DS 1
RDL: DS 1
RDH: DS 1
RGCL: DS 1
RCH: DS 1
RAL: DS 1
RIX: DS 1
RIY: DS 1


который является «Z80 to 8086 Translator version 2.21»
С этим связана одна забавная история, Тиму Патерсону пришлось перетранслировать исходники DOS с ассемблера 8086 обратно на Zilog Z80 чтоб создать MSXDOS1. И прототип MSXDOS предварительно отлаживался именно на IBM PC, а уже потом допиливался до рабочего состояния в течении месяца в Японии на целевой платформе.
CP/M, в отличие от MS-DOS, написана — сюрприз — на языке высокого уровня (PL/M, исходные тексты доступны) и для переноса на 8086 1 к 1 нужно было переписать кодогенерацию транслятора, а не переписывать ассемблерную портянку.
Там есть т.н. BIOS (т.е. HAL), но аналогичный компонент, который надо перепиливать под каждую машину, есть и в MS-DOS. Так что это вообще не задача. Проблема CP/M, пмсм, в нацеленности на более продвинутую ОС, вместо простой перекомпиляции 1 к 1 под новую платформу.
Микрокод был обычным явлением в мэйнфреймах 60-х годов, но ранние микропроцессоры, такие как 6502 и Z-80, не использовали микрокод, поскольку не имели места для его хранения.
Не правда. 6502 имеет микрокод. Подробнее в видео(примерно c 36:20):
Где вы там видите хоть одно упоминание микрокода?
Не правда. 6502 имеет микрокод.

Там же не про микрокод, а про декодер инструкций. Это другое.
Почему это микрокод:
Во-первых он хранится в ПЗУ и может быть изменен.
Во-вторых команды могли бы сразу подаваться на выход декодера — да, они были бы длиннее, да их было бы больше, но вот это было бы то самое "железная логика", где изменить назначение команд нельзя.
Да, этот микрокод не обладает полнотой по Тьюрингу(транслирует одну команду в до 5 последовательных без циклов), но тем не менее его все равно можно рассматривать как код.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации