Comments 161
"...пока не ушли далеко от магазина, покупаем ещё и адаптер для нашего портативного компьютера – чтобы подключать его к телевизору и видеть наш прекрасный разукрашенный синтаксис не в монохроме, а всё-таки в цвете..." - читер! :)
В 1990 были уже вполне себе нормальные PC-шки, а не тот монстр, что показал автор.
В магазине ничего этого купить было нельзя. Доставали через знакомых, за бешеные деньги.
Зачем же фантазировать? Я в 1990 программировал вполне успешно и профессионально, в том числе и на Ассемблере.)
По второму пункту может в США 1990 году и можно было всё это купить
Первое предложение статьи: "Итак, DeLorean доставил вас в США 1990 года."
Тут ещё есть нюанс того как работали компьютерные магазины в США, какой был ассортимент и причём здесь PC 640 ;-) а так-же CGA => TV в стране с NTSC, не адаптеры и шнурки были, но годами ранее...
Точно, блин. Пропустил. Но тогда тем более был ассортимент получше того монстра.
Так что с ассортиментом «не всё так однозначно» ;)
XT в то время можно было на терминалы для банковских клерков пустить. Или учить детишек основам программирования в школах... Короче, что-то вроде современных «малинок» было.
А терминалов на КР580 в СССР и так хватало;)
На ХТ можно было вполне успешно работать как в бизнес сфере, Lotus/SuperCalc
Если повезет, то можно. Ну или старые версии использовать. Просто в какой-то момент пошла мода использовать в реальном режиме инструкции, которые были только в 286 и выше. Ну и часть софта под DOS научилась использовать память за пределом первого мегабайта, что существенно ускоряло их работу, а XT во второй мегабайт лазать не умел от слова «совсем»...
Если повезет, то можно. Ну или старые версии использовать.А зачем было везти? ТР7 отлично работал с ООП и TV, обычный Си в лице ТС2.0 был беспроблемным, на ТС++ 1.1 тоже было вполне нормально писать. Да и все спредшиты работали на 8086, кому охота терять больше четверти рынка США?
Просто в какой-то момент пошла мода использовать в реальном режиме инструкции, которые были только в 286 и выше.Ну у «тормозов» были свои причуды. Нормальные наСИльники и Пасквилянты при тормозах переписывали критические части, кто бы мог подумать, на чистом 8086 ассемблере «ибо нефиг страдать фигней».
Ну и часть софта под DOS научилась использовать память за пределом первого мегабайтаТолько на АТ286 и выше, и только с появлением MS-DOS 5 (1991 год). Навскидку вспомню из DOS программ активно использовавших XMS только DN и QuattroPro. RamDrive/Ncache/Smartdrv не в счет.
что существенно ускоряло их работу, а XT во второй мегабайт лазать не умел от слова «совсем»...А для решения этой проблемы имелся стандарт EMS, который был поддержан куда шире как с аппаратной стороны: были Турбо-ХТ с 2мб памяти где не используемый остаток памяти в 1408кб можно было задействовать как EMS, или купить плату расширения EMS нужного объема. Так и с программной, вплоть до того что оверлеи программ загружались в EMS и вызывались от туда. А уж как любили EMS электронные таблицы и редакторы текста! Так что: Да, но нет. И это без учета того, что можно было из этой EMS создать UMB вверху, переместить наверх DOS, драйвера и резиденты и получить внизу почти 639кб.
ТР7 отлично работал с ООП и TV, обычный Си в лице ТС2.0 был беспроблемным, на ТС++ 1.1 тоже было вполне нормально писать.
Эти-то работали, да.
Да и все спредшиты работали на 8086, кому охота терять больше четверти рынка США?
Сейчас, наверное, уже не вспомню, но кто-то падал, как раз из-за применения 286-ых инструкций. И решение — либо апгрейд машины, либо даунгрейд версии.
А EMS... Да, было. Знатный костыль. Все с него на XMS бежали, если была возможность. Хотя тоже костыль...
Эти-то работали, да.TP 7 was released on 27 October 1992. TC2.0 (late 1988). Turbo C++ 1.0 (in 1990). Вполне актуальные программы разработки рубежа 90-х годов
Сейчас, наверное, уже не вспомню, но кто-то падал, как раз из-за применения 286-ых инструкций. И решение — либо апгрейд машины, либо даунгрейд версии.Не помню таких. В те времена, было хорошим тоном, проверять тип процессора при старте если ты использовал инструкции выше 8086 (NEC V20 и выше), и в случае не исполнения условия выдавал предупреждение и завершал работу программы. А падение без предупреждения, признак… пониженной социальной ответственности. Да и выигрыш, от использования 286 инструкций, часто не превосходил в среднем 5-7%.
А EMS… Да, было. Знатный костыль. Все с него на XMS бежали, если была возможность. Хотя тоже костыль...Костыля бы не было, если бы IBM изначально не решило что 640кб будет достаточно всем, и не сделало архитектуру памяти PC изначально с переключаемыми страницами памяти.
И наоборот, EMS4 был ясен и понятен, окно доступа к EMS могло располагаться везде, а не только в 64кб выше первого мегабайта в XMS. Так что всё было, с точностью до наоборот.
ТР7 отлично работал с ООП и TV
TP7 не работал на 80186 (в начале 00х достался списанный навороченный "Поиск" с винтом на 10Мб и флопиками 5.25 на лето в деревне), специально с интернета скачивал разные версии, самая последняя которая запустилась была TP5.5, на 80286 проблем с запуском ТР7 уже не было, так что я сомневаюсь что ТР7 работал бы на 8088
Так что, что то вы запутались;) Турбина, работала на 8088 на раз.
специально нашел системные требования ТР7
«System Requirements
For the IBM® family of personal computers and all 100% compatibles
512K RAM minimum
Two floppy disk drives or hard disk required for Turbo IDE
High-capacity IDE requires 80286 or higher processor, 2Mb of memory, and hard disk
Mouse support requires Microsoft® mouse or compatible driver, version 6.0 or later»
Похоже действительно запутался, возможно ложные воспоминания. Но отложилось что неделю искал варианты как скачать ТР7.0 а он не запустился, может действительно TPX пробовал, но поидее TURBO.EXE, может там надо было что то настроить, переключить. Эх больше 20 лет назад было. Сейчас даже захотелось полезть на чердак, оживить тот компьютер и проверить с текущим багажом знаний :)
Увы чердак в >3000 км сейчас от меня и в 30 км от линии фронта, посему когда появиться возможность (если к тому времени не забуду конечно) - поеду и проверю.
TP7 не работал на 80186 (в начале 00х достался списанный навороченный "Поиск" с винтом на 10Мб и флопиками 5.25 на лето в деревне
У меня в 90-е был Поиск-1, самый простейший из ХТ-совместимых клонов, без винта, 608К ОЗУ, КМ1810ВМ88 процессор, один дисковод 720К. Так вот, даже на нём работал TP7, хотя с подсветкой синтаксиса и тормозил нещадно. Другое дело, что в комплекте ТР7 были ещё и компиляторы для защищённого режима, которые на ХТ уже не работали. Но для ООП можно было и ТР5.5 юзать, там уже оно появилось.
Там не из-за проца проблемы были, а из-за видео. TP7 хотел VGA-графику по умолчанию, чтобы была красивая псевдографическая IDE. А на «Поисках» было что-то типа MDA/CGA/Hercules, да еще поди с нестандартными адресами. Запускать надо было с ключами, чтобы IDE стартовала в честном тексте без красивостей.
Там не из-за проца проблемы были, а из-за видео. TP7 хотел VGA-графику по умолчанию, чтобы была красивая псевдографическая IDE.TP7 было пофиг на вкусности и красивости VGA, писал он видеопамять текстового буфера в сегменте B000 в случае монохромного адаптера (MDA/HGC), и в сегмент B800 в случае с цветными адаптерами (CGA/EGA/VGA).
А на «Поисках» было что-то типа MDA/CGA/Hercules, да еще поди с нестандартными адресами.На «Поисках» аппаратно эмулировался стандартный CGA (используя NMI), живущий по стандартным адресам и портам в/в. И с точки зрения DOS программы, перед ней был стандартный CGA. Нюансы начинались в том случае, если «особо умная» программа начинала третировать регистры в/к Motorola MC6845, которого в «Поиске» не было. Но турбина к этим «особо умным» программам не относилась.
Добавлено отсюда:
«У Поиска, как уже говорилось, нет физического текстового режима, поэтому когда какая-либо программа пытается что-то записать в область текстовой памяти 0xB800 генерируется немаскируемое аппаратное прерывание и управление передается обработчику Int 2. Обработчик NMI в свою очередь считывает значение из порта 0x28, в котором находится смещение по которому произошла запись в память, и начинает попиксельно рисовать символ в графической видео-памяти 0xBC00. После того, как символ нарисовался в видеопамяти происходит выход из обработчика NMI. Вот примерно по такой упрощенной схеме и происходит визуализация символов из текстового режима в графическом режиме. „
Как ни фига подобного, когда это только подтвердлает мою мысль.
и "рыночный" курс доллара в СССР в конце 1991г. порядка 100р за 1$. и того системник 70000руб :) А я тем временем в 1990г. купил первый ПК (пусть и не PC-совместимый), но тем не менее БК0010-01 за 650руб)
Да, ПК тогда стоил почти как машина. Мы покупали их в очень малых количествах на работу (деньги у оборонки были) и записывались в очередь на поработать) Я тогда тоже купил БК0010, думал написать биоритмы и разбогатеть быстро, сидя у какого-нибудь большого магазина и рассчитывая биоритмы зевакам за деньги. Но что-то пошло не так...)
Тот монстр был в иностранных магазинах, по монстроидальной цене даже для иностранцев (а что, это же ноутбук!), и чуть пораньше, чем в 1990. У нас в это время в магазине или на радиорынке худо-бедно можно было купить "Поиск", "Электронику МС 1502" или "Ассистент-128", ну и в общем-то можно было программировать даже на Турбо-Паскале 5.5 или Турбо Сях++, и почти по-современному, с блэкджеком, ООП и фреймворком Турбо Вижн.
Да, я тоже с 1998 по примерно 2002 писал на ассемблере для PIC и i51, спасибо автору за нахлынувшие приятные воспоминания :)
Насчёт контринтуитивности ассемблера не соглашусь. Да, когнитивная нагрузка неслабая, но ассемблер - это, фактически, окно в процессор с минимумом промежуточных абстракций. Я наоборот, в то время читал Страуструпа и по молодости недоумевал, зачем такие усложнения :)
Но есть вещи, которые ассемблер делает лучше всех.
Лучше всего на ассемблере было писать резидентные программы для DOS. Драйверов в 1990 году еще почти не требовалось. Все оборудование было стандартным и программы напрямую обращались к портам.
А вообще 1990 год - это рассвет Турбо Паскаля ! Там были почти все возможности ассемблера (даже вставки из машинных кодов можно было делать !).
Вот тоже не понятно. Паскаль, как язык, уже был. И даже работал на отечественных клонах 8086. Я, конечно, увидел это позже, чем в 1990 (тогда было ОЧЕНЬ дорого, но было). А писать на паскале намного приятнее (пробовал). Там уже были высокоуровневые процедуры, подключаемые модули, даже оверлеи (или это было позже?). И вставки на том же ассемблере где надо позволяли обходиться малой кровью. И да, писать прямо в видеопамять тогда было можно, иногда даже нужно. Работало как магия.
Там уже были высокоуровневые процедуры, подключаемые модули, даже оверлеи (или это было позже?)
Все это было вроде с 5 версии.
И вставки на том же ассемблере
А это с 6 версии. До этого только вставки машинных кодов.
Единственно чего не позволял турбо паскаль - создать COM-программы. Только EXE.
Все это было вроде с 5 версии.Оверлеи были уже со второй версии ТР
А это с 6 версии. До этого только вставки машинных кодов.Но тем не менее в эти inline можно было прямо обращаться к переменным функции, и я видел в каком то переводном печатном учебнике по ТР3, что в inline могли использоваться мнемоники, а не коды операций.
Единственно чего не позволял турбо паскаль — создать COM-программы. Только EXE.Наоборот, только с четвертой версии ТР научился создавать exe файлы. А до этого были только COM
и я видел в каком то переводном печатном учебнике по ТР3, что в inline могли использоваться мнемоники, а не коды операций.
Не могли там использоваться мнемоники, но приличной практикой у программистов было писать коды в столбик, а за ними в каждой строке в комментах приписывать мнемонику, потому что наизусть соответствие кодов мнемоникам помнили только самые оторванные черти. Возможно, вы как раз такой пример и видели.
Да, было такое. Сам вставлял в код ассемблерные вставки. Правда, не в TP, а в Борланд C++ билдер. Не помню, как команда начиналась, потом открываешь фигурную скобку - и погнали.
asm {
}
Но это совсем уже другая эпоха инструментов разработки. В первых турбопаскалях это выглядело как inline( $F0/$0F/$C7/$C8);
И только где-то с шестой версии, кажется, появился аналогичный оператор asm...end, в середине которого можно было писать мнемоники.
Но это совсем уже другая эпоха инструментов разработки. В первых турбопаскалях это выглядело как inline( $F0/$0F/$C7/$C8);Надо было всего лишь проявить немного фантазии, и Inline становились более человеко-ориентированными.
const
nop=$90;
interrupt=$CD;
mov_ah=$b4;
mov_dl=$b2;
var
i : integer;
begin
for i:=0 to 255 do
inline(mov_ah/$02/
mov_dl/$61/
interrupt/$21
);
end.
Проблема в том, что у Turbo Pascal совместимости снизу вверх по TPU не было от слова совсем. Т.е. коммерческие библиотеки нужно было поддерживать сразу для нескольких версий Turbo Pascal.
В бытность мою студентом, когда работал в лаборатории при кафедре информатики, писали приложение под Turbo Psacal 5.0, т.к. нужная библиотека (коммерческая) была только пол неё.
В отличии от Turbo C/C++, где можно было подключить любую внешнюю бинарную библиотеку, лишь бы заготовочные (.h) файлы были.
Я не могу сказать, что это была прям таки проблема, бинарной совместимости не было, но совместимость по исходникам была, а актуальных версий Турбо-Паскаля было аж три, и в общем-то авторы живых либ спокойно себе собирали их под все три версии.
В отличии от Turbo C/C++, где можно было подключить любую внешнюю бинарную библиотеку, лишь бы заготовочные (.h) файлы были.
В Турбо-Паскале, к слову, так тоже можно было делать без проблем, он хавал тот же формат объектных файлов, что и борландовский С++, но в силу того, что TPU в 1980-х были совершенно имбовой штукой по удобству работы, практически никто компоновку по-сишному не юзал.
Ну, допустим, TASM был опубликован в 1989 году и его уже можно было найти. Но вот редактор TASMED появился уже лет на 6-8 позже, насколько я помню. Быстро нагуглить не удалось, правда.
Ну и по поводу deLorean - нас откуда куда перенесло-то? 1990 находится вообще в будущем относительно даты оригинального фильма.
План, в принципе рабочий, но можно же круче:
Если выкинуло в сша:
1 вариант.
Идем в Юникс, а затем в Линукс в разработчики c++, и дальше, год от года в течении 30 лет, становмися мегагуру Линукса, параллельно выпуская 100500 книжек по софт-скилам и их важности, а так же о прогрессивных методах разработки. Бабосы вкладываем в "Первые в Мире Международные IT-Галеры", организованные где-нить в восточной Европпе, а кадры высасываем из СССР большим пылесосом: был молодой ученый/математик-краснодеревщик-краснодипломнник/Айтишник - стал прогер на галере после допила. После раскрутки материнской конторы в сша бабло можно брать с "Насдака" за свои же акции и вкладывать их в "сателлит". Можно "на своей галере" пилить гугол или фейсбук, но это трудная дорожка. Это если у вас времени дофига. А если на расслабоне, можно просто копить бабосы до бума доткома и удачно там наварить 5х и вложить все в эппле/гугол/микрософт потом. Можно просто Брина найти и сделать прямую инвестицию.
2. Вариант.
Качаться на борланд/микрософт с/с++, ждать прихода винды 3.00 и дальше развиваться по ветке с++ на винде. Либо на дядю пахать, либо пилить какой-нить будущий популярный продукт типа icq, либо игровой проект типа мортал-комбата/дума/кваки/контры на минималках.
А! главное! Если кому "повезет" найдите тех чуваков, которые якобы настоящие авторы Фейсбука и посоветуйте им гнать в шею рыжего проныру!
Еще можно попинать чувака из Нетскейпа, чтобы он сразу пилил Тайпскрипт без порнографии.
Или вот еще можно попытаться попинать толстую ленивую свинью IBM, чтобы они не связывались с рыжим гейтсом и вывели полуось в лидеры.
Если выкинуло в РФ, срочно хоть тушкой хоть чучелком бежать в сша.
Кроме ИТ, можно "сочинять" популярные музыкальные хиты, которые вспомнишь. Можно сценарий терминатора 1-2 написать, и даже более того. Если совесть позволяет - можно троль-патентовать. Очень выгодно можно вложить будет в ПайПал в Маска.
Главное, не лезть в политику и не пытаться изменить особо мир,- просто пробалдеть и сделать по мере сил его чуть-чуть лучше.
А дальше? А дальше строить супербункер, вы же не знаете, чем закончится "этот карибский кризис 2022". Еще можно попытаться что-нить на минималках с Фукусимой порешать, ну хотя бы утуб-ролик запилить, что японцы-лажовщики, и что у них уровень дизель-генераторов "ниже ватерлинии" и разъемы несовместимые с привозными.
А ассемблер... Ассемблер это романтично, но полезно ровно в той степени, чтобы помогало в разработке и отладке на с++.
Нее, вы походу не уловили толщину авторского стёба, тут не в ассемблере дело, а в том что подавляющее число нынешних галеристов, окажись они в девяностых, сосали-бы лапу со всеми своими глубокими знаниями фреймворков ;-)
Помню, в одной школе, попался старый учитель информатики, реальный программист, на BAISIC. Он был стар и в системное программирование уже не мог, но...
...для Агата он запилил текстовый редактор, с векторным шрифтом и многоразличными способами отрисовки оного, причём на экране это всё отображалось условненько, а вот на принтер выходило во всей красе (экран агата так не мог). Тогда только появился лексикон, и самым популярным текстовым редактором был F4 командира Нортона...
Как назывался редактор, помните? Или фамилия учителя?
Полагаю, для современного жителя России, окажись он в 1990 году, вопрос программирования отошел бы на 10-й план и лапу, возможно, пришлось бы сосать в прямом смысле этого слова.
лапу, возможно, пришлось бы сосать в прямом смысле этого слова.
Я помню свои 90-е, это вполне себе сочеталось с программированием. С утреца - на дачу садить помидорчики, поливать помидорчики, опрыскивать помидорчики, собирать жуков с помидорчиков, подвязывать помидорчики, собирать помидорчики. А после обеда за кампухтер. До сих пор ненавижу дачи и помидорчики.
Потом пришла 1с и монополизировала рынок.
Да, ещё где-то в те же времена казино закрыли. Эти за софт вообще бешеные деньги готовы были платить. Эхх…
Бабло текло рекой
К кому-то может и текло, а так, на "рынке" тогда было навалом выпускников советских ВУЗов, готовых работать за тарелку макарон (и я, к слову, был один из них), и всё это здорово мешало грести бабло реками, потому что если ты задерёшь цену, клиенты просто наймут другого такого же.
Оставалось ездить по городу и райцентрам и собирать дань за обслуживание и обновления. Налом.
А кого там выпускали в 90м, хз. Те, с кем я работал, выпускались где-то в середине 70х в основном. Я позже, да, но и вуз у меня непрофильный был.
С казино вообще в наших краях кроме меня никто не работал, насколько я знаю.
Увидел как-то у знакомого буха в соседнем казино бд клиентов в экселе, предложил свой вариант. Через год система работала в половине казино города, остальные очень желали приобрести. Не успели… Но это было чуть позже.
Была ещё мода на мини-АТС. Ставишь в гостиницу, отдельно софтина для тарификации (не было в комплекте).
Потом всё просто покатилось по наклонной. Да и мелкий бизнес задушили напрочь. Или сам сдох. Даже не представляю, где сейчас можно приткнуться, скажем, команде из 3-5 человек. А в 90е — простор для деятельности. в 00х всякие вебстудии повырастали как грибы. Тоже немногие выжили.
Главный вопрос, как и на что жить первое время, да ещё чтобы денег скопить на инвестиции. А так, ближайший к 1990 году мегатрамплин - это ммм94, там при определенной сноровке можно поднять до 100х.
Класс. При биткоин только забыли.
Качаться на борланд/микрософт с/с++, ждать прихода винды 3.00 и дальше развиваться по ветке с++ на винде.И тут придет VisualBasic, и опошлит все прокаченные скилы С++, с отладкой кода на MDA мониторе. Потому что, по другому тут нельзя. Ибо пока вы отдебажите свой проект на плюсах, конкуренты выпустят два десятка корявеньких, но работающих здесь и сейчас программ под Win3.x
А ассемблер… Ассемблер это романтичноЭто не романтика, это суровая правда жизни, боль, пот и кровавые слёзы, а иногда единственный инструмент выбрать тот самый «последний дюйм»
«Эх молодежь!»
Если выкинуло в 90-м в РФ, перед тем как "бежать в США" до 1995-1996 можно поднять достаточно денег на ремонте и на покупке-продаже любого компьютерного оборудования. Спрос на него и на спецов по железу был колоссален. Ехать и обустраиваться надо же было на что-то.
гланое, чтобы братки не забили стрелу ;)
Стрелы они забивали между собой. К спецам по ремонту и покупке-продаже компьютерного оборудования просто приезжали и убедительно объясняли, почему он должен поделиться поднятыми деньгами.
Браткам это не было интересно от слова совсем. Суммы менее 5 штук грина их не возбуждали. Написал все как было у себя. В 92-м, пять сотенных зеленых в кошельке была нормой.
Ну, эт повезло просто. Или место такое. Братков, которые стригли мелкий бизнес по принципу "пять бабулек по 20 коп - уже рупь" у нас было навалом.
Что значит "место"? Газета Из рук в руки. Объявления куплю IBM PC, починю и продам. Профит. Какие братки, вы о чем? Они даже если сперли компьютер, его включить даже были не в состоянии. Для них это было столь же непонятным, как заниматься например брокерской деятельностью на бирже. Одолженная штука грина при должном везении, отбивалась уже за два месяца. А еще был непаханый рынок аон-ов, и сборки ZX, плюс продажи программ. В начале 90-х для знающего то железо - это деньги только что на полу не лежали.
Это какая-то местная аномалия. Братки отжимали и крышевали исключительно тот бизнес, который был им понятен — рынки продуктов питания и одежды, например. Ну или водку с табачкой. Перегон машин. В компьютеры и софт не лезли. Ну или сами давали денег, если кто-то мог им объяснить, что из штуки баксов в этом бизнесе через месяц будет две...
Если цель - "запилить" денег, зная, что и как выстрелит в будущем, то как насчет покупать лотерейные билеты? Или это не тот путь? =)
Такое ощущение, что человек не жил в 1990 году, потому что у статьи должно быть два варианта.
Первый:
Итак, DeLorean доставил вас в США 1990 года. Идем в магазин, покупаем за те же деньги нормальный настольный компьютер на 486-ом процессоре, который от рождения умеет считать с плавающей точкой, ставим на него третью «Винду» и пишем на Turbo Pascal/C++/бейсике примерно так же, как и сейчас. Ассемблер используем либо для критически с точки зрения скорости мест в коде, либо для вирусов.
Второй:
Итак, DeLorean доставил вас в СССР 1990 года.
Несколько недель бегаем, чтобы обзавестись пропиской в том городе, куда попали, и талонами на еду. Обязательный минимум — водка, табак, сахар, мясо, рыба, яйца, масло сливочное, масло подсолнечное, крупы, макароны. Если попали в Ярославль, не забываем записаться на получение книжки покупателя на 1991 год. Затем начинаем играть в топовый квест 1990 года: отоварь талоны. Чтобы в нем победить, нужно найти магазин с едой, зайти в него 30 ноября с ноябрьскими талонами на мясо, майскими талонами на рыбу и декабрьскими талонами на яйца. Зайти нужно путем стояния очереди, периодически меняя на себе татуировки с номером позиции в этой очереди. Разработчики квеста добавили в него элементы шутера от первого лица, забыв дать игрокам рэйл-ганы и IDDQD, поэтому файтинги будут исключительно рукопашными, с использованием подручных предметов. Не забывайте, что после начала файтинга могут приехать милиционеры и зайти со спины с «демократизаторами» типа «Аргумент».
Пройдя первые части квеста и поучаствовав в масс-файтинге за еду, нужно заняться дачными вопросами: купить рассаду помидорных кустов, сделать из чего-нибудь коробочки (это отдельный уровень квеста), посадить рассаду в коробочки и заставить ими подоконники. Последнее заменяет жутко модную компьютерную игру 1990 года «Тетрис»: в «Тетрисе» хотя бы фигурки цветные, но после этого уровня нашего квеста вы с легкостью будете различать 100500 оттенков зеленого цвета и делать такие искажения пространства и времени, которые Эйнштейну и не снились.
После этого у вас должно найтись время для митинга народного фронта за выход из СССР или, если «DeLorean» доставил вас в место, не очень далекое от Москвы, за отмену 6-ой статьи конституции. При попадании в некоторые национальные окраины вам будет предложен бонус-левел: гражданская война на национальной или религиозной почве. Будьте осторожны, на этом левеле у вас будет всего одна жизнь, а IDDQD и IDKFA отключены.
Успешно пройдя все уровни, вы можете включить телевизор и посмотреть новейшее шоу «Поле чудес», которую ведет бывший журналист «Взгляда» Влад Листьев. В рекламных паузах этого шоу вам покажут рекламу новейших 486-ых компьютеров, которые ввозит в СССР только что созданный кооператив «МММ». А потом, около полуночи, не забудьте выключить свой ламповый телевизор, потому что они любят перегреваться и устраивать пожары. Спокойной ночи! Завтра утром вы должны будете пройти этот квест заново.
А где же программирование? Нет, блин, после всего этого вы хотите еще и попрограммировать???
Во втором варианте надо бы добавить что каждому гражданину СССР, конституцией гарантировано право на труд, поэтому весь квест надо проходить в свободное от работы время.
На дворе 1989, комп PC Olivetti Prodest PC1, город вдалеке от столиц, CCCР, сидел и программировал на asm и basic, дефицит был конечно, но если навык доставать и крутится был, то все решаемо. Персики и абрикосы летом были настоящие со своего огорода, а в столицах уже запахло беспределом. 1992, уже не СССР, 286 asm C. Правда деньги зарабатывались на продаже ZX Spectrum, пока шахтеры касками стучали.
но если навык доставать и крутится был
Я посмотрел только что, он стоил в то время в Италии порядка 1200000 лир в базовой комплектации, что по тогдашнему курсу около 1000 американских долларов. Совершенно безумная и космическая сумма для советского человека. Так что навыка "доставать и крутиться" явно было недостаточно, в цепочке поставки сего чуда из итальянского магазина на стол советского человека ещё у кого-то должен был быть как минимум навык "отжать" или хотя бы "спереть".
Персики и абрикосы летом были настоящие со своего огорода
У нас с этим проблемы были, и тогда, и сейчас...
Первый:«Фантазёр, а мы с тобою не пара»
Итак, DeLorean доставил вас в США 1990 года. Идем в магазин, покупаем за те же деньги нормальный настольный компьютер на 486-ом процессоре, который от рождения умеет считать с плавающей точкой, ставим на него третью «Винду» и пишем на Turbo Pascal/C++/бейсике примерно так же, как и сейчас. Ассемблер используем либо для критически с точки зрения скорости мест в коде, либо для вирусов.
Нельзя так просто взять и купить 486 комп в США 1990 года, и ваш осётр урезается до:
386sx@16/1mb/fdd1,2 & 1.44mb/40mb/SVGA800x600x16 цветов одновременно за сущие 1099.99$ без монитора. А если вы у нас купите «SVGA» монитор 14 дюймов с 0,39 dot pinch (кто знает в чем подвох молчите) за жалкие 329.99$, то мы сделаем скидку на системник в сто (100) баксов и но вам обойдется в 999.99$. И это еще оптимальный вариант, IBM PS/1 на 286 в базовой конфигурации вам обойдется в 1589.99$
Кстати, в октябре 1989 года в NY Times писал о 486 «NCR is among several companies that have already announced they are in the race to sell the first 80486-based systems. For prices expected to be $10,000 to $20,000»
Спортивный альманах вы ещё не выкинули? ;) Может пора делать ставки Биф?
А что чуть что так ассемблер, в 80-е вполне себе бухгалтерия используя Basic на Wang'e и на его импортозаместительном аналоге Искра-226 работала, Fortran также использовали, ну это уже на больших машинах. А в 90-м, если годик подождать так в 91-м так и HTML появится, вот вам и день рождения фронтэнда. Кстати, а почему в 90-й год? Почему бы не в 80-й, вы попадаете туда, идете ТУ(техническое училище) где готовят телемастеров, набираетесь практиса и денег на левых заказах, во второй половине 80-х начинаете собирать Спектрумы, продаете их по демпинговой цене в 800 рублей,осваиваете Basic, пишете игры, продаете их, становитесь кооператором в кожаном пиджаке, потом 90-е и понеслось HTML, Perl, Java...
Главное при попадании в 1990-е годы США, не забыть "спортивный альманах 2000".
В 1990 году приходилось знать как минимум три вида ассемблера. Есть сферы где без ассемблера никуда и сегодня. Да что там сегодня, прямо сейчас ...
А сейчас где, кроме микроконтроллеров и изучения вирусов?
Драйвера, например. Криптография. Какие-то специальные вычисления.
Вот вы включаете ваш настольный компьютер. Процессор проходит reset sequence и выставляет на шину адрес, чтобы выбрать первую инструкцию из памяти. Что это за инструкция? Варианты:
Это часть программы, скомпилированной с питона
Это часть программы на ассемблере, написанной лично Биллом Гейтсом в 1978 году, и с тех пор к ней никто не прикасался.
Это магический код вселенной, который поместил в память компьютера святой дух.
Варианты
Все три неверные ;) Первая инструкция там - кусок бутблока BIOSа, которая написана скорее всего на C, лет на 30 позже Билла Гейтса (который, к слову, загрузчики BIOSа и не писал никогда). Ну ладно, может быть, один-единственный джамп с FFF0 на основную точку входа в бутблок там в сурцах действительно прописан в виде ассемблерной команды, хотя тоже не факт.
А вам не приходит в голову, что делать джамп прямо из reset vector в функцию написанную на си не получится например потому что сишная функция ожидает уже подготовленный указатель стека? Или вы думаете, что указатель стека сразу будет стоять правильно в момент сброса на всех процессорах, и x86, и Apple ARM-based, и новомодных линуксных ноутбуках с RISC-V?
Нет, но ведь бутблок - как раз та часть биоса, которая ни разу не кросс-платформенная. В старых х86 начальное значение стека не детерминировано, как сейчас, хз, не интересовался. В армах оно предопределено, но в любом случае, если вы современный разработчик биосов, вы про это не будете думать, это на себя возьмёт тулсет, с помощью которого вы образ биоса собираете.
А тулсеты на деревьях растут? Или разработчикам тулсетов ассемблер знать тоже не нужно? За него код на ассемблере AI напишет? Разработчику надо только на питоне написать AI который сам прочитает интеловский мануал и внесёт в свою нейросеть знание ассемблера?
Короче, я только что позвонил своему приятелю Алексу Белицу, который видел биос от Финикса в исходниках в 2012 году. Его компания работала с финиксом Говорит что почти все на ассемблере, только небольшой кусок сетапа на си. Можете его найти на Фейсбуке Alex Belits и распросить прямо.
В legacy bios-ах очень долго тянули всякий мусор, в uefi биосах почти все было переписано на C. (мне IDA рассказала)
ИДЕ можно верить, она знает. Но предполагаю, первые команды настройки сегментных регистров, стека, контроллера памяти, все равно должны быть на ассемблере. Вот в защищенный режим не знаю, где современные системы переходят. Помню, друг писал свой (аналог dos4gw/cwsdpmi/dpmiinst?). Из доса сначала в защищенный, а потом туда-сюда гонял, чтобы прерывания реального режима выполнить, и вернуться в защищенный. С отладкой были проблемы... Если зависало, отправлял FF в порт 20 и смотрел, когда начинало перезагружаться. Если перезагружалось - то вставлял FA F4.
Даже в обычной программе есть что-то, что выполняется до main(). для х86 давно не смотрел, но для Cortex M3 (CMSIS?) там все очень похоже на нативный ассемблеровский код.
Прикол, что там еще и контроллер памяти не инициализирован. В современных железках есть режим CAR(cache as ram). А раньше был код на регистрах, либо специальный компилятор. Но вообще в современных биосах (начиная с UEFI) ассемблера очень мало.
Не знаю как сейчас с этим делом обстоит, но когда в те годы программировал в C++ билдере, то знание ассемблера выручало. Неоднократно ловил билдер на ошибках компиляции, заглядывая в ассемблер.
Выглядит это так. Все отлажено и работает в дебаг версии. Компилируешь релизную с оптимизациями - не работает. Начинаешь отлаживать, находишь место, где происходит что-то очень странное. Заглядываешь в код на ассемблере - а там фигня. Скомпилировано совсем не то, что написано. Переписываешь пару строк по другому - и взлетает. Причем без оптимизаций компилирует нормальный код.
Это удивительно, но мэйнфреймы в Техасе, на которых ПО Sabre обсчитывало данные для Аэрофлота, требовали поддержки разработчика на ассемблере... ещё в начале этого года.
У вас нет ассамблера в магазине? Что ж, возможно, придется нащелкать его с пульта программатора (вспоминая журнал "Радио" второй половины 80-х)
Ничего страшного, нащелкаем, там всего два кило))
Для человека, который эмулировал технологию сканирования (чтобы впихнуть фотку в игрушку, писаную на 580-м проце) через увеличение оригинала, разлиновку копии в миллиметровую сетку и ручной ввод полученных байтов -- это все фигня, а не задача :)
нет, с программатора тумблерами - "Монитор". Дальше можно в кодах набирать. """
М 8000
8000> 3E 00 21 00 80 CD 06 F8 3E 20 ...""" или типа того.
тумблеры < коды < ассемблер < С < ...
*** Как программист из 2022-го вы сталкивались с ассемблером разве что на лабораторных работах в университете. ***
Понятно, вы считаете, что компиляторы, ядра операционных систем и низкоуровневые библиотеки то ли растут на деревьях, то ли их все написали 30 лет назад (кстати тогда говорили "ассемблер использовали только в 1960-е годы").
Я даже не говорю про разработчиков микропроцессоров (представляете, такие есть даже в России - Syntacore, НИИСИ, НПЦ Элвис и другие) для которых ассемблер нужен для написания процессорных стестов и вообще своего рода архитектурный API к их микроархитектурным реализациям.
Справедливости ради, ни компиляторы, ни ядра операционных систем, ни низкоуровневые библиотеки на ассемблере уже давным-давно не пишут, по крайней мере, в промышленной разработке. Это и слишком долго, и слишком дорого, и предъявляет повышенные требования к разработчикам и к контролю качества. Естественно, бывают энтузиасты, у которых есть подобные пет-проекты, но погоды они не делают. Единственное применение ассемблера, в которое попасть шансы не нулевые - это embedded-разработка, и то, даже там чаще вы будете с чем-то более высокоуровневым сталкиваться.
Охххх, это же надо так понять то что я написал. Товарищ, я не сказал, что компиляторы пишут на ассемблере. Я вообще-то автор трех компиляторов, про один из которых есть в википедии. Писателю компилятора нужно знать ассембер просто по той причине, что он генерит инструкции процессора.
Далее, я в курсе, что даже самые малые RTOS-ы в основном пишутся на Си. Но как вы обойдетесь без знания ассемблера в обработчике прерывания, в котором нужно сохранять или переключать регистровый контекст, запрещать другие прерывания и переходить, если нужно в "большой" обработчик на Си?
Насчет библиотек: когда вы пишете оптимизированную библиотеку скажем для матричного умножения в AI, которая использует векторные регистры, вам тоже не нужен ассемблер? Вы думаете компилятор понимает все о векторизации и конкретном поведении конвейера конкретного процессорного ядра в таких случаях.
Я работал в MIPS Technologies и лично наблюдал, как человек писал в 2019 году оптимизированную последовательность ассемблерных инструкций для быстрого выполнения AI функций с помощью векторного расширения процессорных ядер MIPS P5600 и MIPS I6500 (первое используется в процессоре Байкал-Т, второе лицензировано японской компанией denso для автомобильной электроники).
Вы также можете писать си-функцию с ассемблерными вставками, но это тоже ассемблер.
*** отсутствие интринсиков для недавно появившихся инструкций (ничего, добавят в следующей версии компилятора), и ***
Вы все правильно говорите, и вот как раз в 10 метрах от товарища, который писал эту последовательность инструкций - сидел другой товарищ, который добавлял интринсики в компиляторы GCC и LLVM, а еще на некотором расстоянии от них сидел архитектор, который придумывал новые инструкции, и целая куча народу (включая меня) которая эта инструкции реализовывала в RTL и верифицировала.
То есть это не некое обезличенное "добавят", а конкретные люди, и всем этим людям нужно знать ассемблер, а не только "видеть его на лабах в институте".
В компиляторах еще есть встроенные функции для работы с векторными расширениями, например _mm256_add_ps в intel c++ compiler, не говоря уже от куче врапперов и мат. библиотек доступных для любого ЯВУ, многие из которых еще и могут перенести расчеты на видеокарту.
В ОСРВ действительно единственное место где нужен асм это сохранение/восстановление контекста и переключение стеков, в остальном работа с памятью и периферией на си.
Это все понятно, но ведь врапперы и встроенные функции же не на деревьях ростут, их пишут конкретные люди в конкретных корпорациях (в том же интеле) за зарплату. И если вы один из них - вам нужно знать ассемблер. Таких людей на самом деле не так уж и мало - отдел software stacks в любой процессорной, SoCб DSP итд компании.
В ОСРВ это не единственное место. Есть еще boot, в котором нужно поставить стек, инициализировать кэши и устравление виртуальной памятью (фиксированный MMU есть даже в микроконтроллерах), поставить конфигурацию контроллера прерываний и только потом перейти на сишную программу. Пример такой минимальной последовательности см. напр. (беру первый попавшийся из мне известных) https://github.com/MIPSfpga/mipsfpga-plus/blob/master/programs/03_cache_misses/boot.S
В RTOS которые поддерживают аппаратную многопоточность, например ThreadX, есть и другие места, где нужны ассемблерные вставки для определенных процессоров, чторбы работать с этой многопоточностью. Они тоже wrapped в макросах, но они есть.
Я просмотрел пост снова и понял, что автор либо гонит пургу чтобы потролить народ, либо имеет о 1990 годе совершенно фантастическое представление типа того, что при Сталине жил Пушкин.
В 1990 году у x86 компьютеров повсеместно были хард драйвы. Небольшие 20-60 mb но хард. Встретить 8088 с двумя флопиками A и B это было ну как сейчас встретить на дороге Шевроле 1975 года. X86 с двумя флопиками были в самом начале, в 1980 году, но их быстро вытеснили компьютеры с хард драйвами (сначала xt, потом at).
В смысле ассемблера 1990 год вообще не отличался от 2022, ни на йоту. Никто в 1990 году не использовал ассемблер для писания прикладных программ. Прикладные программы на ассемблере (например для бухгалтерии в штатах и для всяких расчетов) писали в 1960 году, на 30 лет раньше, хотя уже тогда переходили на Фортран, алгол и Кобол.
В 1990 году, как и сейчас, ассемблер использовали для:
Части кода драйверов
Ассемблер нужно было знать разработчику бэкэнда компилятора
Высокооптимизированные математические библиотеки, использующие тонкое знание поведения инструкций конкретного процессора (конвейеризация, векторность, распределение регистров)
Обработчики прерываний и boot последовательности в операционных системах
Вообще, точно так же как и сейчас, для таких задач использовали смесь ассемблера и Си. Переход на Си с языков типа Паскаля произошел с примерно 1980 года до 1985.
Игры для разнообразных 8-16-битных игровых платформ в 1990 и до примерно 1995 ещё довольно активно писали на ассемблере. На C произошёл массовый переход только с приходом 32-битных платформ.
Это не совсем так. Насколько я помню (хотя могу ошибаться) игры от компании Konami на компьютерах MSX Yamaha с 8-битным процессором Z80 уже с 1985 года писали на смеси C (компилятор ASCII C) и ассемблера.
Процент написанных на C игр года игр для приставок и домашних компьютеров тех лет, особенно для 8-битных, очень мал. И он в основном сосредоточен на платформе PC/MS-DOS, где память и скорость не были так сильно ограничены (компилированный код в несколько раз больше, не говоря про скорость, это большая проблема на 8-битных платформах).
Про Konami я подобное слышу впервые и очень сильно сомневаюсь. Похожие слухи ходили про игры KOEI на Famicom, но и там это только на уровне догадок, потому что код выглядит странно. Пока все игры, исходники которых открывались авторами, были написаны на ассемблере.
Я не буду особенно спорить по поводу Konami, но хочу уточнить вашу фразу "компилированный код в несколько раз больше, не говоря про скорость". Вы имеете в виду неоптимизирующие компиляторы на 8-битных машинах? Потому что кросс-компиляторы того времени (например основанные на PCC - Portable C Compiler) уже оптимизировали неплохо, умели размещать переменные на регистрах, а не только в стеке и памяти, использовали числа Сети-Ульмана для аллокаций регистров и оптимального вычисления выражений, и в результате код был не "в несколько раз больше". Современные же (2022) компиляторы для ARM и RISC-V с уровнем оптимизации -O2 могут сгенерить год лучше, чем придет в голову большинству человеческих ассамблерописателей.
Для MSX Yamaha в 1980-е было минимум три Си-компилятора (Aztec C, BDS C и ASCII MSX-C), первые два действительно генерили плохой код, а вот последний получше
Я имею в виду современные кросс-компиляторы для старых 8-битных процессоров. Размер скомпилированного кода для процессоров уровня 6502 и Z80 очень сильно больше, чем можно написать руками, и это представляет большую проблему в условиях ограниченной памяти и страничной адресации. Современные компиляторы для ARM и RISC-V никакого отношения к этому не имеют, для старых процессоров подобных сверх-эффективных компиляторов нет и быть не может, в виду особенностей их архитектуры.
Ну насчет "быть не может принципиально" - это имхо не факт. Я думаю, что если вбить в компилятор много распознования шаблонов, а также глобальный анализ иерархии вызовов и control flow, то можно заоптимизировать сильно, но другое дело, что делать это сейчас профессиональным компиляторщикам для старых 6502 и Z80 нет вообще никакой мотивации, а для хоббистов это слишком много изучения специализированных алгоритмов и их реализации.
По сути, принципиальная разница в том, что 6502 - типичная аккумуляторная архитектура, Z80 - расширение аккумуляторной архитектуры с разнофункциональными регистрами, а ARM и RISC-V - это register-rich RISC архитектура. Плюс системы адресации и всякий изврат в Z80 типа (hl), который можно покрыть шаблонами.
Вы можете привести пример двух последовательностей - скомпилированной и ручной чтобы я понял какие случаи вы имеете в виду (я ассемблер Z80 еще помню, а про 6502 догадаюсь)?
6502 определённо не типичная аккумуляторная архитектура, она вообще мало на что похожа (на прото-RISC, всего 53 инструкции) - большую часть кода занимают явные обращения к памяти. Т.е. если на Z80 что-то загрузил в регистры, можно некоторое время выполнять алгоритм чисто в регистрах, и следующее обращение к памяти будет уже записью результата. На 6502 же постоянно делаются операции с памятью, вплоть до inc addr и сразу же lda тот же addr, чтобы сделать сравнение, не достиг ли счётчик нужного значения, а в целом в коде значения в регистрах задерживаются очень ненадолго.
ARM и RISC-V изначально делались с прицелом на компиляторы ЯВУ, а не на ручное написание кода. У 6502 и Z80 среди опкодов нет примитивов, необходимых для эффективной компиляции кода с ЯВУ, и вместо одного опкода там то и дело надо десяток. И у них нет даже элементарных операций целочисленного умножения-деления, так что для эффективности приходится вставлять шаблонные процедуры умножения-деления на константу, наиболее оптимальным для конкретной константы кодом.
Нет, готовых примеров у меня под рукой нет, и заниматься их целенаправленным созданием мне не очень интересно.
Размер скомпилированного кода для процессоров уровня 6502 и Z80 очень сильно больше, чем можно написать рукамиНе всё так плохо, к примеру энтузиасты на этом форуме вполне успешно пилят оптимизатор Ассемблера Z80.
Да и Hitech C, для Zilog Z80, до сих пор выдает не плохие результаты.
Энтузиасты настолько успешно запилили оптимизации в SDCC для Z80, что им уже очень давно стало просто невозможно пользоваться, и немало проектов загнулось.
'Неплохие результаты' никак не противоречат тому, что код получается сильно неоптимальным, и прежде всего неоптимальным по размеру. Да, компиляторами C можно пользоваться на 8-битках. Я сам приложил усилия к демонстрации этого, и это привело к появлению сотни-другой игр для NES, написанных на C, а Mojon Twins ещё раньше популяризировали то же самое для ZX Spectrum, и там счёт игр ещё больше. Но практика демонстрирует, что нехватка памяти становится очень существенной проблемой, даже более существенной, чем потеря в производительности.
P.S. Для 6502 пилят CC64 (Си компилятор) в рамках использования Форт, как языка разработки компилятора.
Энтузиасты настолько успешно запилили оптимизации в SDCC для Z80, что им уже очень давно стало просто невозможно пользоваться, и немало проектов загнулось.Не знаю, SDCC последний раз пользовался лет десять-двенадцать назад.
Надо посмотреть как он работает в 8bitworkshop IDE
'Неплохие результаты' никак не противоречат тому, что код получается сильно неоптимальным, и прежде всего неоптимальным по размеру.Дело в том что я вам привёл ссылку на программу которая оптимизирует именно Ассемблер, неважно сгенерирован он компилятором или написан руками.
Да, компиляторами C можно пользоваться на 8-битках.И можно и нужно. Хотя бы в целях прототипирования и отладки внутренней логики.
Я сам приложил усилия к демонстрации этого, и это привело к появлению сотни-другой игр для NES, написанных на C,А сколько бы их было, если бы вы ограничились только Ассемблером?
а Mojon Twins ещё раньше популяризировали то же самое для ZX Spectrum,Вот Спектрум, в свете нативной разработки на самой платформе, пардон муа никакашка. Си можно пользоваться только при кросс-разработке, ЧТМ запустить вариант усеченного Small или RAT Си, и скомпилировать «Hello World!», но всё что крупнее будет превращаться в боль
Но практика демонстрирует, что нехватка памяти становится очень существенной проблемой, даже более существенной, чем потеря в производительности.Памяти много не бывает;)
Тем более, если писать «неоптимально», то на реализацию игры «крестики/нолики» может и 16гб не хватить:)
Это не размер кода у компилятора получается больше, а на ассемблере просто пишется другой код, нежели на C. Если переписать руками на ассемблер в точности то же, что написано на C, с соблюдением ABI, то выигрыша особого перед компилятором и не будет. Будет такая же унылая адресация переменных через IX+n и ничего нового не придумаешь.
В значительной степени ручное программирование выигрывает от отсутствия жёстко заданного соглашения о вызовах, от размещения данных в static-переменных, а не на стеке, от отсутствия integral promotion. Часто от самомодификации кода (размещения данных в коде операций, например в инструкции LD HL, #XXYY можно это самое XXYY переписать путём обращения к памяти по адресу где располагается инструкция +1 байт). Такой подход на самом деле-то не очень-то и хорош (исключает рекурсивные функции, вызов функций в прерываниях и многопоточность), но быстрей. Ещё поддержка, развитие, модификация такого кода -- проблема. Отсутствие соглашения о вызовах значит, что в каждом случае, для каждой функции по-своему определяется, какие регистры она портит, какие не портит, и обычно это всё совершенно не документируется. Внесение любых изменений -- ошибки и сбои. Повторное использование кода -- невозможно, как и какой-то рефакторинг. Любая программа -- глюкавый монолит.
На C произошёл массовый переход только с приходом 32-битных платформ.Не совсем правильно, массовый переход на Си произошел с появлением доступных компиляторов Си. Для 8080/z80 это был BDS C, который доказал, если я не ошибаюсь, саму возможность создания компилятора Си на 8 разрядном процессоре.
А с 16 разрядными 68000 (да я знаю регистры были 32 разрядные, но АЛУ то могло обрабатывать только 16 бит), всё было еще проще, Си существовал изначально и активно использовался при создании софта.
С приходом 32-битных платформ стало нормой иметь из коробки SDK от платформодержателя, и эти SDK для 3DO и PS1 изначально подразумевали разработку на C/C++, с компилятором и библиотеками. Для 8-16 битных платформ официальных SDK просто не было, а 99% самопальных сред разработки и решений от третьих лиц использовали ассемблер. И нет, компиляторы C для 68000 при создании игр для той же Амиги (до середины 90-х), Atari ST или Sega Megadrive активно не использовались. Большинство игр для этих платформ написано на ассемблере, хотя компиляторы C стали доступны достаточно рано.
С приходом 32-битных платформВы имели ввиду приставок?
нормой иметь из коробки SDKАссоциация MSX изначально давала возможность ознакомиться с MSX Red Book и MSX Technical Data Book описывающих стандарт MSX, а после выхода стандарта MSX2 стала доступна MSX2 Technical Handbook. А инструменты для разработки, были доступны ранее в СР/М (microsoft m80/l80 и так далее)
от платформодержателяА платформодержатель это кто?
и эти SDK для 3DO и PS1 изначально подразумевали разработку на C/C++, с компилятором и библиотеками.приставки != ПК, на приставках нельзя осуществлять разработку внутри платформы. Только кросскомпиляция и отладка.
Для 8-16 битных платформ официальных SDK просто не было, а 99% самопальных сред разработки и решений от третьих лиц использовали ассемблер.А использование ассемблера это уже табу?
Arnor C 1.00 (no math lib, originally for Amstrad CPCs)
ASCII C 1.1 (for MSX-DOS, which is almost CP/M compatible)
Aztec C 1.06d
BDS-C 1.6 & 2.0 (complete package for CP/M + ZCPR3)
Ecosoft C Compiler 3.43 (Z80; thanks to Rolf Harrmann !)
HiTech C 3.09 (Z80. locally mirrored) and a manual for it (locally mirrored)
HiSoft C 1.35
ManxC 1.05
Mi-C 3.18
Mix C Compiler 2.0
Mix C Compiler 2.1 — see Bill Buckels web pages
Q/C Compiler V3.1a (Z80, Codeworks aka Quality Computer Systems)
SIL 1.5 from Digilog (with a subset of C, but with some other extensions)
Small C 2.1 (no float, partly K & R, source exists here)
Small C 2.7 (created by F. A. Scacchitti in Oct. 1986)
Small C 1.2 with floats (Z80, SIG/M 224)
Small C/Plus with floats and structs/unions (v1.0, 1988)
Another Small C variant named MESCC with code optimizations from Miguel I. García López can be found at his webpage, an old local mirror is here (he has also a Github page with a current version)
Supersoft C 1.3 (not sure all needed files are included, plz feedback)
Whitesmith C 2.0 (seems complete)
Whitesmith C 2.1 (now also complete !)
И нет, компиляторы C для 68000 при создании игр для той же Амиги (до середины 90-х), Atari STЭто надо смотреть по текстам ошибок рунтайма в бинарниках.
или Sega Megadrive активно не использовались.А вот тут вы ошибаетесь, кроссразработка приложения на приставку удобна именно на ЯВУ.
Большинство игр для этих платформ написано на ассемблере,Пока игры были относительно небольшими, и не сложными. И плюс были эксклюзивами только для этой платформы. Как только требовалось закрыть несколько платформ, язык Си, а с ним и Паскаль становились предпочтительнее, так это существенно ускоряло перенос программ и игр.
хотя компиляторы C стали доступны достаточно рано.Быть доступным, и быть удобным для работы — это две больших разницы.
Про 1990-й год не скажу, но уже в 1991-ом в не самом крутом ВУЗе Москвы - МАСИ - вовсю использовались 286AT/XT для обучения студентов. Писали программы на Фортране, на встроенном языке Автокада (мышки были еще редкостью, чертили командами с клавиатуры). В 1992 году мне был выделен "личный" 286-й с частотой 20 МГц, оперативой 1 МБ и жестким диском 20 Мб. В составе MS-DOS был QBasic с примерами программ.
В 1989 вышел мой любимый Clarion Database Developer. Уже были Clipper и FoxPro, не говоря уже о Pascal и С. Так что выбор языков и сред программирования в 1990 году был вполне богат.
В 1990 у народа повсеместно не было компьютеров. И запросто встречались в больших количествах советские Нейроны и болгарские Правец в которых жёсткий диск то не работал, то отсутствовал, то его смехотворный размер (5-10Мб) не позволял на нём разместить ничего кроме десятка важных программ. Поэтому дискеты были очень даже в ходу, и запросто встречались варианты именно что с двумя A: и B:, но без C:. Даже где-то помню был только A: и там ДОС писал, надо вставить дискету A или B. Работать можно было с одним дисководом, но очень неудобно.
На ассемблере было написано уйма разных программ для ДОС, в основном любительских. В основном из-за того, что на C оно не лезло в память. Тот же Volkov Commander занимал 64кБ, а Нортон -- "половину дискеты". И при работе с дискетами первый можно было тупо положить на каждую дискету. Собственно сам ДОС наверняка был написан на асеемблере, по большей части (не знаю если честно, но не верю, что проект такого уровня в каком-нибудь Turbo-C был подъёмным).
Было много программ на Turbo-Pascal, но последний умел генерировать относительно компактный код. И в Turbo-Pascal были ассемблерные вставки, что очень помогало во многих ситуациях.
А вот C в DOS на мой взгляд начал массовое появление только с появлением i386 и так называемых DOS-экстендеров (наподобии DOS4GW), позволяющих переключать процессор в защищённый 32-битный режим и исполнять там программу. Вспоминается Watcom-C, например. Впрочем в те времена уже подоспели 32-битные Windows, OS/2 и Linux, где всё было куда более по-человечески и можно было нормально программировать на C. А в рамках сегментной памяти это было как-то сильно неудобно.
Про микроконтроллеры автор тоже ничего не понимает или сознательно троллит чтобы вызвать комменты микроконтроллерщиков. Все эти stm32, pic32, AVR и прочие программируются в основном на си, хотя ассемблер разумеется возникает в boot sequence, обработке прерываний и вставках __ asm. Чисто на ассемблере было принято программировать микроконтроллеры а-ля 8051 давно.
Вот цитата автора, троллит людей словом "обычно":
"Большое направление программирования на ассемблере – это написание программ для микроконтроллеров. У этих девайсов обычно большие ограничения по мощности процессора и объёму памяти, так что в этом случае ассемблер – это не альтернатива, а единственное средство решения задачи."
в 1990 и были только MCS51. про PIC стало широко известно где-то в середине 90х, AVR к концу 90х.. STM32 были еще позже.
А в 512б...2 кб памяти программ для микроконтроллера сильно не разгуляешься, так что ассемблер.
В 90м году в СССР любой умеющий держать паяльник мог за среднюю зарплату собрать Спектрум, там Бэйсик прошит. Можно в игры играть и т.п. Устроившись в госконтору можно было кодить на Паскаль на IBM PC, вспоминаем Турбо Паскаль. В те годы набирал обороты Си и Си++. Так что статья мура, а на Ассемблере под ARM коллеги что-то писали сегодня.
Не знаю, что за демонизация сложности ассемблера такая, но в 1990 12-13 летние пацаны осваивали его и без интернета, и без stack overflow, и без хорошо написанных книг, на тех компьютерах или их подобиях, до которых удавалось дотянуться. Это в разное время происходило во всех странах.
Именно! Кому интересно было - осваивали...
Поддержу. Я выпускную работу в школе на ассемблере (x86+DOS) писал. Сложного нет, просто нужно понять архитектуру железа. Но это все-таки был выпендреж (смотрите, как я могу), если бы я ту софтину писал «на продажу» или «на заказ», то писал бы на чем-нибудь высокоуровневом, ибо прерывание 21h запоминается на всю жизнь, а вот что там в регистрах — это надо каждый раз исходник со справочником смотреть...
Ноутбук, конечно, мажорский.
Я в 1990-м как раз программировал на ассемблере... КР580ВМ80А, у меня был "Партнёр 01.01" (семейство РК-86, но ОЗУ и ПЗУ было побольше). По умолчанию, как и во всех РК-86-подобных, был шрифт на основе КОИ-7, с заглавными русскими и латинскими буквами. Но в ПЗУ в виде двух половинок была прошита ISO 8859-5, она же "основная кодировка ГОСТ", и я бился над тем, как эти половинки сопрячь вместе. У видеочипа ВГ75 был служебный невидимый байт, позволявший после его размещения в памяти переключаться на другой шрифт, и в зависимости от режима он мог либо занимать знакоместо на экране (выглядеть пробелом), либо не занимать (но в этом случае терялось однозначное соответствие между адресом в памяти и ячейкой на экране). Каким-то чудом я заставил второй вариант работать, написал улучшенный драйвер клавиатуры-экрана и даже выдвигал его на местный конкурс партнёрщиков. Правда, системную программу притащил я один, остальные игрушки демонстрировали.
Ассемблер-транслятор и редактор, к счастью, были в ПЗУ, но вот текст своего кода приходилось грузить с магнитофона и на него же записывать. Отредактировал, записал, оттранслировал, всё зависло - грузим с магнитофона по новой и думаем, где ошибка. Ни флопиков, ни тем более хардов. Контроллер дисковода, правда, потом в продаже появился, но это было потом, да и дисковод для студента-третьекурсника стоил, мягко говоря, существенную сумму...
Весело было, короче.
Такое ощущение, что ассемблер - какая-то окаменелость, а не низкоуровневый язык программирования. Кстати, в 90-м он считался "среднеуровневым", т.к. были еще машинные коды. Но в любом случае: на чем, по мнению автора, сейчас программируют чипы? Для чего в даташитах пишут asm команды?
А так в 90-м на дискете надо было иметь турбо паскаль, а ассемблер включать только инлайном для резидентов и прочего шаманства с регистрами и прерываниями.
Машинный код после 1960-го года использовали только в программируемых калькуляторах, учебнике МГУ 1970-х и в брошуре серии "Популярные лекции по математике". В 1990-м ассемблер был однозначно низкоуровневым языком программирования, как и в 1970-м.
Окаменелостью ассемблер не является и являться не будет, пока будут существовать процессоры общего назначения построенные на парадигме фон-неймана, то есть выполняющие цепочку инструкций, которые они получают из памяти.
Что касается вопроса "на чем программируют чипы?" то он несколько глубже, чем ассемблер. Посколько с голыми чипами есть два уровня - архитектуры, системы команд (на этом уровне работает ассемблер) и микроархитектуры, устройства железа процессора - стадии конвейера, устройство арифметических блоков, структура кэшей итд.
И вот для второго уровня есть языки описания аппаратуры - Verilog, SystemVerilog и VHDL, на которых описывается структура процессора и этот код с помощью технологии логического синтеза превращается не просто в "машинный код" (в машинный код превращается ассемблер), а в файл геометрических фигур (GDSII) по которому выпекают чипы на фабрике. То есть это код превращается в транзисторы и дорожки. Вот сравните:
После чего все вместе работает так:
Вот бы это в виде статьи увидеть, особенно про плисы (я не шучу).
Я по книжкам в начале 90-х помню, что там ассемблер называли "человекочитаемыми машинными кодами" и потому он был "среднего уровня". Возможно, они уже тогда устарели, но вроде там речь шла о 286, и показывалось, как из ASM сделать машинные команды (хотя лично у меня не было возможности это проверить, только инлайн). Ведь там по сути они и есть - буковки заменяют циферки. НО! можно читать и писать по-человечкски.
Машинный код после 1960-го года использовали только в программируемых калькуляторах
Для ПЛИС и сейчас иногда возникает необходимость заюзать машинный код в рамках микропрограммного конечного автомата, ассемблер рожать под это дело выглядит оверкилом обычно.
Ассемблер сложный не из-за того что он сложный, а из-за всратого дизайна. Зачем мне так MVI C, 9 MOV A, D если можно так C:=9, A:=D и далее AX+=666h
Вот нормальные асмы могут так.
;--------- регистрируем группу клавиш (Buttons) ---------
mov iNum, GROUP_BTNS_ID
mov bmAtlasButtons, LoadBitmap(hInstance, IDB_BITMAP_BUTTONS)
mov buttDC, CreateCompatibleDC(NULL)
mov tmpHGDIOBJ1, SelectObject(buttDC, bmAtlasButtons)
mov butY, BlockKeysY+butDistHeight
.for (edi=0, ebx=0: edi<6: edi++);Y - edi, N - ebx
mov butX, BlockKeysX
.for (esi=0: esi<5: esi++, ebx++);X - esi
mov hGroupButtons[ebx*4], CreateWindowEx(0, &aButton, NULL, MS_BASE_BUTTON, butX, butY, butWidth, butHeight, hWnd, iNum, hInstance, 0)
mov bmTemp, CreateCompatibleBitmap(buttDC, butWidth, butHeight)
mov imageDC, CreateCompatibleDC(NULL)
mov tmpHGDIOBJ0, SelectObject(imageDC, bmTemp)
imul edx, esi, butWidth
imul ecx, edi, butHeight
BitBlt(imageDC, 0, 0, butWidth, butHeight, buttDC, edx, ecx, SRCCOPY)
SendMessage(hGroupButtons[ebx*4], BM_SETIMAGE, IMAGE_BITMAP, bmTemp)
SelectObject(imageDC, tmpHGDIOBJ0)
DeleteDC(imageDC)
inc iNum
add butX, butWidth+butDistWidth
.endfor
add butY, butHeight+butDistHeight
.endfor
SelectObject(buttDC, tmpHGDIOBJ1)
DeleteDC(buttDC)
DeleteObject(bmAtlasButtons)Всё понятно, что С что даже С++, даже этакой асм намного более понятный. Хотя можно и лучше.
А тогда программистам тоже платили 100500 денег в секунду?
А удаленка была?)
Как программист из 2022-го вы сталкивались с ассемблером разве что на лабораторных работах в университете.
Иногда в реальных задачах что-то на интринсиках изображать приходится))
У меня первый комп появился в 1991 году, это был БК-001/01 с магнитофоном, подключался к телевизору. Потом был прокачан до чёрно-белого монитора, для цветных игр был доработан, чтобы выводил вместо цвета градации серого. Затем был приобретён 5.25" дисковод, потом 3.5" дисковод, и наконец 40 МБ винчестер, и более мощный компьютер БК-0011М. Для разработки был доступен Бейсик, Фокал, ну и ассемблер, более навороченный, со множеством способов адресации. На ассемблер рано или поздно приходится перейти, чтобы добиться большей производительности. Причём до этого программировали на нём прямо в машкодах, восьмиричное представление команд довольно удобно читается для архитектуры PDP-11, но не хватало меток, при относительной адресации надо самому считать длину смещения.
Практически весь софт для БК был написан энтузиастами, кроме игр было большое количество прикладного софта и утилит, на БК-0011М было достаточно памяти (128 КБ) для реализации чего угодно, на БК-0010 приходилось сильно ужиматься, чтобы программа влезла в 16 КБ, или в 28 КБ при использовании 1/4 экрана для вывода информации. Было написано множество дисковых операционных систем, самые популярные это ANDOS и MKDOS, поставлялись с файловыми менеджерами типа Norton Commander.
спасибо, что возвратили в назад в будущее, как будто посмотрел новую серию, тех. аспект статьи важен, но атмосфера важнее
Эхх... и незабвенный журнал Монитор с конкурсами и задачками на оптимизацию ассемблерного кода.
Чем программисту заняться в 1990 году: осваиваем чёрную магию ассемблера