Войти
ФлеймФорумЖелезо

Блеск и нищета 8/16-битных консолей и ПК (73 стр)

Страницы: 170 71 72 73 74 75 Следующая »
#1080
(Правка: 15:17) 15:09, 14 июля 2020

Gradius
> до уровня бредогенератора
библия это не бредни.
Gradius
> ответом
хотелось бы ответ технического стиля : делали так и вот так,такими методами и способами.
Gradius
> Схему консоли выложил - берите, делайте
исторически так и сделала IBM PC открыла лицензии и доступы , потому IBM PC и клон-совместимые делали все кому не лень и захватило рынок.в то время как Apple Macintosh никому не позволяло производить свои компьютеры.сама владела лицензиями,сама делала. как знать может история была бы иная и сейчас было бы не windows PC заправляло всем, а какая нибудь system Macintosh правила бы.


#1081
15:30, 14 июля 2020

Rikk
> библия это не бредни

Бредни, это то как вы её постом выше проинтерпретировали. Проверил вас на вшивость - сказанное вами слишком далеко от оригинала.

Rikk
> хотелось бы ответ технического стиля : делали так и вот так,такими методами и
> способами.

В настоящий момент времени я сильно занят и мне лень подробно расписывать.


Rikk
> Apple Macintosh никому не позволяло производить свои компьютеры.сама владела
> лицензиями,сама делала. как знать может история была бы иная и сейчас было бы
> не windows PC заправляло всем, а какая нибудь system Macintosh правила бы.

Свою долю признания на рынке Джобс получил.  Я нисколько не на его стороне, скажу даже больше - мне он противен, но факт - есть факт

#1082
(Правка: 15:39) 15:38, 14 июля 2020

Rikk
> исторически так и сделала IBM PC открыла лицензии и доступы

История там намного пикантнее.
Надо понимать, что IBM специализировалась в те годы на "больших решениях" - больших ЭВМ для большого бизнеса (International Business Machines) и делала она на этом некислые бабки.
Компьютеры персонального формата она выпускала и до IBM PC: https://ru.wikipedia.org/wiki/IBM_5100 но это всё-равно было дорогое "профессиональное" решение. Немаловажно тут заметить, что 5100 использовал собственный процессор (не микро-) IBM: PALM, т.к. IBM всё сама могла и умела делать без посторонней помощи.
Но для дома и мелкого бизнеса эта штука подходила слабо, поэтому возник побочный проект "Project Chess" который и вылился в IBM PC. Так вот учитывая существующую толкучку на рынке "несерьёзных" персоналок где всякие игрульки на коммодорах и эпплах только были в этот проект руководство фирмы верило слабо и просто спустило его на тормозах и чтобы не мешать основному бизнесу дало главный посыл: использовать сторонние компоненты которые можно купить в любом радиомагазине.
Именно поэтому в IBM PC нет процессора от IBM, а есть процессор от Intel. Что интересно - гипотетически IBM могла бы выбрать в качестве ЦП для своего PC 16-битный процессор Zilog, но Zilog тогда купила Exxon (нефтянка) и в рамках диверсификации рынка хотела составить конкуренцию всему и вся и потому Zilog воспринималась IBM как конкурент.
Вот это вот наплевательско-пессимистичное отношение и породило ту ситуацию, что IBM PC не оказался обложен патентами по самое не балуйся и стал восприниматься как открытый стандарт. Юристы IBM просто проспали непонятный побочный бесперспективняк.
Когда же IBM поняла какой денежный продукт породила, то она попыталась закуклить джинна обратно в бутылку: IBM PS/2

Основной рыночной задачей серии PS/2 было вытеснение с рынка персональных IBM PC-совместимых компьютеров других производителей Америки, а также выпускаемых в регионе Юго-Восточной Азии. Главным способом достижения этой цели стало использование закрытых стандартов, в том числе шины, использующей микроканальную архитектуру (англ. Micro Channel Architecture, MCA), не допускающих их использование сторонними разработчиками без дорогого лицензирования, и выпуск сложных для воспроизводства небольшими компаниями микросхем высокой степени интеграции.

И вот тут уже встрепенулись фирмы хорошо кормящиеся на рынке и стали выдумывать свою шину с блекджеком и _умеренными роялтями_, пока наконец то не пришла Intel и не разогнала всех желающих еще подзаработать на стандарте выпустив свободную спецификацию PCI. Конечно же исключительно в корыстных и коварных целях.

Вот так недальновидность и жадность выковали нам свободную компьютерную архитектуру.

#1083
10:32, 4 авг. 2020

Забавный фактик на nesdev обнаружил (англ.): http://forums.nesdev.com/viewtopic.php?f=2&t=15931
Есть такая японская игростроительная фирма - Koei.
Основана она была в 1978 году и разумеется в начале истории выпускала кучу игр для 8-биток.
И в этом смысле фирма была всеядной - одни и те же игры выпускала и на NES и на MSX и на Amiga и на DOS и PC-98 и каких то уже мало мне известных FM-7, Sharp X1, Sharp X68000 и WonderSwan.
В общем плодовитость и по числу игр и по платформам где они выходили даже в ранние 8/16-битные годы была существенной.

Так вот - некто AWJ с форумов nesdev обнаружил, что все игры этой компании на NES кроме Mahjong Taikai используют один и тот же байткод некоей виртуальной машины которая по своему внутреннему устройству как будто бы создана для того чтобы интерпретировать код на Си.
Немного позднее по теме выяснится, что в игре Aerobiz Supersonic от этой же фирмы на SNES в ROM картриджа сохранились небольшие фрагменты кода на Си: https://tcrf.net/Aerobiz_Supersonic_%28SNES%29 так что эта догадка блестяще подтвердилась - Koei явно использовала Си для кроссплатформы и на разных платформах видимо использовала разные виртуальные машины для интерпретации байткода, который суть уплотнял код так что его проще было запихать в ограниченные картриджи.
Более того - как минимум 1988 года и на 16-битных системах этот Koei Си мог генерировать и полноценный машинный код и более того - перемежать в одном и том же проекте машинную компиляцию с компиляцией в байткод.

Чем была сия виртуальная машина на NES он там описывает ниже по теме, я только вкратце обрисую.
Машина в начале памяти (в zero-page MOS 6502) располагает свои регистры, три из которых 16-битные, а два - 32-битные:

адрес| разм | регистр
-----+------+----------------
$02  |  2   | указатель стека (SP)
$04  |  2   | указатель фрейма (BP)
$06  |  2   | указатель инструкции (PC)
$08  |  4   | "левый" регистр
$0C  |  4   | "правый" регистр
Левый и правый регистры названы так самим AWS в силу того, что в первый попадает результат операции, а в правом хранится операнд как во всяких a += b;

Вся арифметика совершенно по сишному или 16-битна или 32-битна. 8-битные значения сперва расширяются до 16 бит еще при загрузке в регистры.
Каждая функция в байткоде начинается с машинной инструкции MOS 6502 вызова интерпретатора (JSR) и заголовка обозначающего сколько у функции локальных переменных и т.п. Интерпретатор реентерабельный и таким образом вплетается бесшовно в машинный код. Поэтому инструкция вызова машинного кода и инструкция вызова байт-кода в интерпретаторе есть одна и та же инструкция.
Кроме интерпретатора игры обычно содержат небольшое количество машинного кода - ну как сами интерпретатор так и обработчики прерываний и всякие вещи которые требовали тяжёлой оптимизации, но их вроде бы совсем немного обычно.

Так что похоже такая плодовитость конторы была неслучайной и подпитывалась внедрением передовых технологий и виртуальных кросс-платформенных машин прямо в 8 бит! :) Довольно забавно.
Еще судя по топику в некоторые функции типа strlen и abs вкрались ошибки, но их не заметили видимо потому что их не использовали или очень мало использовали.

#1084
21:50, 4 авг. 2020

=A=L=X=
> используют один и тот же байткод некоей виртуальной машины которая по своему
> внутреннему устройству как будто бы создана для того чтобы интерпретировать код
> на Си
А нафига байткод? Почему бы сразу не компилировать Си в машинный код?

#1085
22:55, 4 авг. 2020
А нафига байткод? Почему бы сразу не компилировать Си в машинный код?
который суть уплотнял код так что его проще было запихать в ограниченные картриджи.
#1086
(Правка: 6:08) 5:45, 5 авг. 2020

Panzerschrek[CN]
> А нафига байткод? Почему бы сразу не компилировать Си в машинный код?

Да, такой байт-код намного плотнее машинного кода. А на такой 8-битке как MOS 6502 так вообще - просто в разы.
Основная масса кода в таких играх - 16-битная и сама виртуальная машина это поддерживает - все основные короткие виды инструкций - 16-битные, а например вся 32-битная машинерия делается через префикс инструкции 0xB7.
Кстати тут как раз выявляется забавность - инструкция 0xB728 по логике вещей должна была бы быть logical not (!LEFT) для 32-битного LEFT, но скорее всего по ошибке делает то же самое что 32-битное left != right (код 0xB71D). AWS прошерстил все игры Koei на NES и обнаружил что ни в одной из них не используется 32-битный logical not, так что видимо поэтому баг остался необнаруженным в своё время.

Так вот машинный код 6502 очень неплотен если речь идёт про 16-битные вычисления - сложение например надо делать в несколько операций постоянно перекладывая из аккумулятора в память. Даже просто загрузка константы (вшитой в код) в 16-битную ячейку памяти - это четыре инструкции в худшем случае занимающие 10 байт. Да, они выполнятся максимально быстро, но займут 10 байт.

Байткод Koei же использует много трюков для оптимизации размера.
Так в нём очень много вариантов инструкций LOADL, LOADR и STORE. Это загрузки левого и правого регистров и сохранение левого регистра (результата) соответственно (названия выдумал AWS).
Много инструкций имеет в 16-ричном представлении вид 0xAB, где A - это код инструкции, а B - непосредственное данное от 0 до 15.
Так вот во первых есть такие 1-байтовые инструкции LOADL/LOADR где можно в LEFT или RIGHT за 1 байт загрузить число от 0 до 15 (с расширением до 16 бит).
Во вторых существуют однобайтовые варианты и LOADL/LOADR и STORE где число 0-15 обозначает 16-битное значение в стеке - от 0 до 11 это локальные переменные функции (отрицательные смещения от указателя фрейма) и 12-15 это четыре 16-битных аргумента (возможных конечно же). Таким образом 4 аргумента и 12 локальных переменных в байткоде Koei можно очень эффективно адресовать.
Если этого не хватает есть уже двухбайтовые варианты этих инструкций где 1 байт выделен на смещение и, наконец, трёхбайтовые где можно адресовать всю память 16-битной машины.
Практически вся арифметика/логика делается так - сперва в LEFT/RIGHT загружаются через вышеприведённые инструкции два аргумента и потом идёт опкод выполняющий нечто вроде LEFT *= RIGHT, и далее через STORE результат сохраняется обратно в стек. Единственная инструкция у которой есть вариант работающий сразу с непосредственным данным (0-16) или данным в стеке по короткой адресации - это ADD. Как опять таки понятно - потому что часто нужно и существенно сэкономит размер.
Так, например, вещи типа if ( a >= b ) { ... } делаются так: a и b грузятся в регистры, выполняется operator>= который поместит в LEFT 0 если условие ложно или 1 если условие истинно (т.е. то как булевы реально в спецификации Си должны приводится к int) и единственные инструкции условных переходов в самой виртуальной машине Koei выполняются если LEFT==0 и если LEFT!=0.
В общем плотность кода в такой среде конечно же вырастает и просто в разы.
Однако и скорость выполнения сильно падает - по моим оценкам где то на порядок.
На слабенькой 8-битной денди это было бы фатально, но тут видимо помогает то, что основная масса игр Koei в ту эпоху была всяческими стратегическими симуляторами, например менеджеры управления аэропортами, древними японскими империями и т.п. Т.е. игры медленные, вдумчивые, и не требующие от видеочипа невероятных эквилибристик на пределе возможного.
Видимо так и выкручивались.

Ну и вообще не Koei единственная придумала уплотнять код в виртуальной машине - я пару месяцев назад описывал как это делал никто иной как сам Стив Возняк в своём интерпретаторе Basic на Apple II - как раз с тем же самым процессором MOS 6502: https://gamedev.ru/flame/forum/?id=226622&page=65&m=5183022#m974
При этом его SWEET16 был по сути голой виртуальной машиной/процессором и писать на нём - всё равно что писать на ассемблере, поэтому по сравнению с монстром Koei это очень маленькая и простая виртуальная машина.

#1087
13:00, 5 авг. 2020

=A=L=X=
> Да, такой байт-код намного плотнее машинного кода.

> Так вот машинный код 6502 очень неплотен если речь идёт про 16-битные
> вычисления - сложение например надо делать в несколько операций постоянно
> перекладывая из аккумулятора в память

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

#1088
(Правка: 13:39) 13:30, 5 авг. 2020

Panzerschrek[CN]
> Спрашивается - куда смотрели разработчики процессоров? Почему команды делали
> столь длинными? Ведь памяти тогда было весьма мало, да и кешей не было.

Для меня это вообще интересная тема. Эффективность процессоров общего назначения. Это проблема далеко не только 8-биток.
Но для начала конкретно про MOS 6502: этот микропроцессор поистине дёшев был и сердит.
В 1975 году он вышел на рынок, где цены на аналоги начинались от $179. А он стоил $25! Для рынка это был взрыв породивший кучу архитектур на базе этой штуки.
Однако он реально был сердит - так примерно треть его опкодов вообще не было использовано! https://www.masswerk.at/6502/6502_instruction_set.html
Одно это только уже как понятно понижает плотность кода.
Повышает в нём плотность кода адресация первых 256 байт ОЗУ через однобайтовые смещения - команды становятся двухбайтовыми. Но как понятно далеко не всё влазило в первую страницу памяти.
А теперь предположим простейшую задачу - скопировать 1 байт данных из произвольного адреса в памяти в другой байт.
На ассемблере 6502 это будет примерно так:

lda addr1 ; загрузить в аккумулятор байт из 16-битного адреса addr1
sta addr2 ; сохранить аккумулятор в адрес addr2
Здесь два опкода и два 16-битных адреса - т.е. на один скопированный эффективный байт данных процессору пришлось прочитать из той же самой памяти шесть байт программы.
Эффективность один к трём - 1 полезное чтение+1 полезная запись должны сопровождаться шестью чтениями программы.
Не очень хорошо, но еще грустнее станет когда мы захотим скопировать данные в цикле - перебросить кусок памяти из одного места в другое.
Обобщённая процедура memcopy на 6502 будет обладать эффективностью где-то около 1 к 10-20 - т.е. процессор 90-95% времени занимается не полезной работой, а обслуживающими действиями.

В процессоре-конкуренте от Intel где есть инкременты регистровых пар эту эффективность можно поднять где то до 1 к 5 если не ошибаюсь. Лень сейчас считать.
В Z80 же есть строковая команда LDIR, но она двухбайтовая, тем не менее это поднимает эффективность до 1 к 2 - дело в том что её опкод на каждой итерации считывается снова и снова, т.е. она просто совершает переход сама на себя пока не завершится цикл по счётчику. Тем не менее 1 к 2 это уже очень круто на фоне 6502.

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

И технически сейчас ситуация обстоит похожим, но уже изменённым способом.
Если посмотреть на те машинные коды что сейчас рожают компиляторы для тех же вещей: https://godbolt.org/z/1ocxs6

move1():
8A 44 24 FE 
mov al,BYTE PTR [rsp-0x2]
88 44 24 FF 
mov BYTE PTR [rsp-0x1],al
C3 
ret 
Тут двоякая ситуация - с одной стороны качество 1 к 4, что не очень хорошо даже в сравнении с 8-битным 6502 (!), но с другой стороны видно что смещения используются байтовые, два байта на команду отожрали просто суффиксы ModR/M если не ошибаюсь. Но на самом деле очень неплохо что в стеке можно байтовыми смещениями оперировать. Понятно что если бы мы копировали байт как в 8-битке из полного адреса в полный адрес, то качество сразу провалилось бы ниже плинтуса за счёт 8-байтового адреса. Хотя там вроде можно 4-байтовый использовать...
В общем вопрос интересный. Совершенно не зря всякими SSE поднимали качество кода на удобных данных и т.п.

#1089
14:06, 5 авг. 2020

=A=L=X=
> Тут двоякая ситуация - с одной стороны качество 1 к 4, что не очень хорошо даже в сравнении с 8-битным 6502 (!)
В древних x86 для такого был REP MOVS, а в современных процессорах никто не будет по одному байту копировать, к тому же небольшие циклы целиком попадут в кеш микроопераций и все доступы к памяти будут только по делу.

#1090
14:10, 5 авг. 2020

}:+()___ [Smile]

Ну это да, я уже просто не стал много рассуждать. Сильно поднимает эту эффективность кода в современных реалиях большая разрядность данных над которыми за раз оперируем в среднем и кеш конечно.
Но всё равно такие анализы заставляют задуматься. Взять вон те же ARM-ы которые начали повышать эффективность кода внедрением Thumb-инструкций - причём в два этапа - Thumb-1 который тупо был под 16-битную шину данных сделан, а потом и Thumb-2 который уже конкретно метил в повышенную плотность кода даже на 32-битных системах.

#1091
(Правка: 20:45) 20:33, 5 авг. 2020

Интересно, а почему в общее употребление не вошли процессоры/контроллеры MISC архитектуры, неужели только из-за дороговизны иметь стековую память внутри кристалла + набор регистров?
(или индустрия компиляторостроения в них не увидела потенциалa)

http://users.ece.cmu.edu/~koopman/stack_computers/sec4_5.html
http://soton.mpeforth.com/flag/jfar/vol6/no1/article1.pdf
https://en.wikichip.org/w/images/4/44/MARC4_4-bit_Microcontroller… 27s_Guide.pdf
http://ultratechnology.forthfiles.net/chips.htm

P.S. Хотя RTX2010 стал вполне упешным процессором в разработках NASA. 

#1092
21:09, 5 авг. 2020

=A=L=X=
Есть у меня предположение, что ширина команды была следствием экономии на их декодировщике.
Я где-то читал, что в те времена техпроцесс был сильно несовершенным, было много брака, вплоть до того, что 1 на 10 или даже 1 на 100 кристалл был без дефектов. При таком раскладе любое повышение сложности схемы приводило к увеличению брака и повышению стоимости, иногда даже в разы.Поэтому делали максимально просто, ценой усложнения программирования и увеличения требований к памяти.

#1093
5:16, 6 авг. 2020

Panzerschrek[CN]

Ну да.
Решительное, кстати, удешевление MOS 6502 было еще связано с тем что MOS Technology как раз к моменту выпуска перешла на новые на тот момент ультрасовременные технологии - NMOS и "дистанционные" маски. Транзисторы по NMOS были заметно энергоэффективнее, что позволяло делать чипы меньших размеров, а чем меньше размер чипа на технологической пластине кремния, тем меньше шансов что она выпадет на участок пластины с физическим браком. Кроме того ранее изготовленную маску со схемой физически надо было вводить в контакт с пластиной кремния из-за чего срок её службы исчислялся десятками применений. Тут же придумали что маска зависает над пластиной, а через неё светят (наверное ультрафиолетом) и потому маски (а их изготовление было сильным геморроем) стали гораздо дольше служить. Это всё всовокупе позволило сильно снизить стоимость микропроцессоров.
Тем не менее неплотность системы команд - незанятые слоты - не давала покоя и были производные чипы например WDC 65C02 где часть неиспользованных слотов использовали под новые инструкции.

Так или иначе в целом то, что микропроцессору чтобы выполнить полезной работы на 10 байт данных надо считать из той же памяти 20 байт программы и до сих пор происходит нередко. Это сам принцип работы general processors - программа это солиднейший кусок данных с которым мы вынуждены работать by design.

#1094
7:55, 6 авг. 2020

=A=L=X=
> Это сам принцип работы general processors

Ну если гарвардская архитектура (с раздельными памятью данных и памятью программ, но это все равно general processor) - тогда этой  проблемы нет (ну за исключением случаев необходимости чтения данных из памяти программ).

Страницы: 170 71 72 73 74 75 Следующая »
ФлеймФорумЖелезо