Сообщение Re[6]: История компьютеров в СССР от 18.09.2023 18:57
Изменено 18.09.2023 19:08 vdimas
Re[6]: История компьютеров в СССР
Здравствуйте, netch80, Вы писали:
N>Даже для x86 сделать полноценный OoO стоило настолько дорого, что Intel это осилил только тогда, когда на него свалился дождь золота за ASCI Red.
Дык, я ж и говорю, что все деньги подгребли под себя гаврики без соотв.компетенции:
N>Это при том, что x86 по сравнению с PDP-11 это полу-RISC в том смысле, что не более одного аргумента в памяти. А вот 68k намеренно накачивали по максимуму CISC-фичами — всеми этими 100500 преавтодекрементными адресациями.
Это легко реализуется и в RISC, бо логика простейшая, что и показал ARM.
Плюс оно же прекрасно обыгрывается не только через OoO, но и через спекулятивное исполнение с отбрасыванием проигравших веток вычислений, как в Эльбрусе.
N>Да, это было сильно позже — последний из 68k общего назначения вышел в 1994. Но мины под будущее были заложены ещё при начальном проектировании.
Да там "мина" была только в том, что Apple проиграла конкуренцию IBM/PC, из-за чего Motorola не имела достаточных денег на дальнейшее развитие среди топа процов.
88k был сырым-провальным.
V>>У нас в ВУЗ-е была машинка с 2 МБ оперативки, а 4 было стандартом во второй половине 70-х.
N>4MB во второй половине 70-х? Не смеши. 256KB, 512KB — верю. 4MB — нет.
У них было.
У нас 2 метра на машинке конца 70-х.
N>К этому уровню модели верхнего уровня у нас дошли лет на 10 позже, как раз ко всеобщему развалу.
Ерунду какую-то говоришь. ))
N>>>(I/D разделение в старших моделях не в счёт, 8086 хотя бы давал сегментные префиксы.)
V>>Что давало ограничение сверху 1 МБ.
N>128KB если один процесс. Ты странно считаешь, мягко говоря.
Ты опять ерунду говоришь, мягко говоря.
Сегментная адресация добавляет 4 разряда к 16-ти.
Я мог адресовать из свой программы ровно 1 метр памяти (если он там был). ))
V>>Это ты уже подзабыл за давностью лет. ))
V>>Если у тебя размер массива был более 64к байт, то начинались пляски с бубном при его итерации и сравнении указателей.
N>И использовать такой массив можно было только в huge модели с huge указателями, а не far.
Не, huge модель тормозила безбожно, и поэтому была практически невостребованной, бо там перевод формата адреса на каждый чих.
Нам хватало 64к элементов массива (и даже намного меньше), но это намного больше 64к байт памяти (хранятся структуры по-значению).
Ссылаться напрямую на элементы (элементы выстроены в двунаправленный граф) — это аж 4 байта, перерасход памяти!
Дешевле было ссылаться по индексу.
Далее.
Итерировать такой массив быстрее всего было ручками, пробегаясь по сегментам и смещениям в двух вложенных циклах.
Я это и имел ввиду — геммор. ))
V>>Проблема была даже в представлении таблицы переходов грамматики — вместо указателей приходилось использовать индексы, чтобы ужаться в 2-байтное представление, из которого каждый божий раз надо было ручками рожать FAR-указатель.
V>>Почему ручками?
Потому что непосредственное манипулирование сегментным регистром и смещением намного эффективнее, чем рождаемый компилятором код из абстрактного исходника.
Собсно, навыки "битовыжимания" шлифовались когда-то из-за угрёбищности x86-й архитектуры. ))
Плюс, компиляторы тех лет давали периодические баги в huge-адресации, мы сотоварищи нашли минимум 3 тогда, избегали определённых конструкций.
V>>Для IBM PC любой из них подошёл бы несравненно лучше.
N>M68k ещё как-то согласен. PDP-11 — нет и нет.
И как же ДВК-3М шла в базе с 248 кб? ))
N>>>Базовые вычислительные операции в 8086 (не 8080) можно было делать между любыми целочисленными регистрами, или ты забыл?
V>>Да какие "любые"? ))
V>>По-факту, в свободном доступе у нас только 4 регистра: A, B, C, D (префиксы-суфиксы E-X опускаю)
N>Я не понимаю, почему ты пропускаешь SI и DI. Это для целочисленных операций полноценные регистры.
Потому что по ним обычно лежит предвычисленное смещение в памяти — вычисления же молотят содержимое памяти...
V>>ОК, готов смириться со специальными индексными, базовым, стековым, но когда многие команды автоматом задевают упомянутые 4 — это уже беспредел.
N>И сколько таких многих?
Это без которых невозможно программировать в любом случае.
V>>По каждой такой команде необходимо помнить, какие регистры она неявно трогает (в каких регистрах надо подготовить данные и откуда потом забирать).
V>>В других асмах неявно дёргается разве что аккумулятор/флаги, остальное указывается явно — код быстро пишется и легко читается .
N>Это уже особенности стиля, да. Я так и не запомнил, где cwd, где cwde (для AT&T — cltq и clto). Лучше бы их писали в стиле <sexti куда, откуда> и <esxto куда, откуда>, даже если куда и откуда фиксированы.
+1
V>>В общем, ASM 8086 — это всегда было отдельной вселенной.
V>>Недостаточно быть "просто крутым ассемблерщиком", надо быть спецом именно по этой архитектуре и... полностью бесполезным для других.
V>>И обратное тоже где-то верно.
N>Нет, общие принципы сохраняются.
Настолько общие, что на практике требуется несколько дней при очередном подходе к 8086-архитектуре, пока опять в памяти всё не уляжется.
Для других архитектур "освежить навыки" — единицы часов или меньше.
Тут м/у языками высокого уровня когда переключаешься — и то порой некоторое время надо на перенастройку...
А там реально, каждый божий раз после некоторого перерыва раз как в новой области себя пробуешь.
Если уж начистоту, то это где-то даже унизительно.
V>>В общем, я что студентом недоумевал/возмущался, что эта кретиническая архитектура постепенно завоёвывает рынок, что сейчас уже машу рукой, но мнение не поменялось, конечно.
N>Я их кретинизм вижу совсем в другом и это не 086, это минимум 286 и дальше.
Ес-но, я говорю о развитии этого всего в 32 бита в i386-м.
Понятно же, что 16 бит были компромиссом сугубо для персоналок, когда в мейнстриме уже лет 20 было 32 бита в мейнфреймах и уже на тот момент в персональных рабочих станциях.
Как компромисс мы бы еще пережили эти вшивые 16 бит, бо им всё-равно уже маячил конец в середине 80-х...
Но они, собаки, сделали аппаратный режим виртуального 8086-го в i386-м, сделав гладкую возможность исполнять накопленное ранее бестолковейшее 16-битное ПО!
Не забудем, не простим! ))
ПО должно переноситься исключительно на уровне исходников, а не бинарников... а то развели бардак, панимашь...
Приучили к плохому...
Вон, в UNIX всё по-уму сделали еще за 10 лет до, POSIX уже закрепился независимо ни от каких операционок, а им подавай бинарную совместимость.
Идиотизм? — очередной он самый.
N>DAT без лёгкого выключения. Безумные шлюзы прерываний. Сегментация внутри виртуального пространства вместо индексации таких пространств (как сделала та же IBM). И т.д. Но уже возможность использовать любой регистр как адресный в 32-битном режиме исправила заметные проблемы.
Но кодировка инструкций доставляла — инструкции по 5-7 байт...
К лопате присобачили кофеварку, рядом садовые ножницы и вот так вырос этот франкенштейн...
Смотреть на это доставляет профессиональную боль...
Понятно же, что начни они разработку с 0-ля, без стремления к унификации с 8086, они бы сделали по-уму...
Но, но...
И эти AMD64 забили последний гвоздь в эту крышку гроба...
Теперь всё, 64 бита уж точно надолго хватит, это не "64к достаточно любой программе".
Т.е., даже в Intel прекрасно осознавали, что они натворили... хотели было исправиться...
А уже фигвам, уже созданные ими же обстоятельства были непреодолимей благородных желаний, бгг...
V>>Сейчас разрабатывать оптимизирующие компиляторы под эту архитектуру стало намного легче, конечно, ведь ADM64 узаконил доп. файл векторных регистров — теперь оптимизирующие компиляторы "почему-то" охотно используют именно их даже не в векторных операциях, бгг...
N>Ну вообще-то SSE предназначен был и для замены x87...
Стандарты SSE опицональны для реализаций x86-совместимых архитектур, AMD тут помог обязаловкой этого файла регистров хотя бы в x64-архитектуре.
ИМХО, им стоило бы сделать маленький шажок — вообще избавиться от унаследованных регистров общего назначения и тупо оставить пару файлов регистров общего назначения, поверх которых теперь есть векторные инструкции.
Я где-то понимаю, что необходимость выполнять в x64 так же 32-битные приложения продиктовали, что ле, некоторую преемственность, но тут нет никаких технических моментов, кроме психологических, ведь эти режимы неодновременны, а внутренний ремаппинг регистров делает фиолетово, как этот регистр называется на ассемблере. ))
А разработанная с 0-ля кодировка инструкций для x64 режима могла бы оботись без того Франкенштейна, который получился из изначально простой лопаты.
Сдаётся мне, что они струхнули сугубо в деле компиляторостроения, боялись, что ниасилят, бо так-то достаточно было подкрутить компилятор gcc x86 в сторону окучивания x64, поменяв совсем немного — только принцип оперирования сегментными регистрами.
N>Сейчас пишут всякие универсальные распределители. И чем бы тут ИИ помог?
В пределе это задача с огромным перебором вариантов, что неприемлимо на практике, бо скорость работы компилятора тоже важна.
ИИ мог бы где-нить в фоне "учиться" на сотнях разновидностей процов одной архитектуры, бесконечно перебирая варианты.
V>>Представь этот же код для 8086 — появятся лишние команды тусования данных по регистрам или в стек и обратно.
N>Представил. Всё равно мало таких операций.
Плохо представил. ))
V>>На PDP-11 и VAX отработали несколько моделей внешних ускорителей с плавучкой — система команд никак не влияла на представление плавучки.
V>>И именно DEC явился тем полигоном, на которых эти форматы были испробованы/отработаны и закреплены в международных стандартах.
N>IEEE был отработан на DEC? Дай ссылку.
IEEE был зафиксирован вовсе не в DEC, просто для одной и той же архитектуры DEC шли различные варианты блока вычислений с плавающей точкой с различным представлениями и правилами оперирования. Некоторые из вариантов поддерживали IEEE-784 задолго до появления этого стандарта. ))
V>>Сейчас ведь уже легко ответить на вопрос, что лучше — "отлитая из бетона" плавучка в IBM 360/370, или "оставленная на выяснение по ходу пьесы" модель PDP-11/VAX?
N>Что там могли оставить на выяснение, если для конкретной команды формат был фиксирован?
Само представление числа с плавающей точкой и правила работы с ним не были фиксированы.
Это были просто инструкции, которые генерировали определённые наборы сигналов в управляющей схеме, к которой подключался незавимиый модуль вычислений с плавающей точкой.
Это почему DEC-компьютеры можно было модернизировать в том числе повышая им производительность в плавучке, а в случае IBM 360/370 модернизация касалась только размера оперативки и периферии.
V>>Принятый в IBM 360/370 формат и соотв. правила оперирования им уступали более поздним разработкам, но!
V>>Система команд IBM 360/370 никак не опиралась на формат плавучки, т.е. этот формат мог быть доработан позже, а программы пересобраны из исходников.
N>См. выше.
На что смотреть?
Формат плавучки для IBM 360 найти легко. ))
N>И что значит "никак не опиралась" при наличии, например, ненормализующих команд?
Так а что эти команды меняют в бинарнике?
Для модульной архитектуры команда означала выдачу определённого кода на внешний сопроцессор, а для "литой" архитектуры IBM 360 — "что-то происходит с регистром".
Даже приведение к целому и обратно — этим занимается сопроцессор.
Команды — разложить на порядок и мантису или собрать обратно — аналогично.
Тут уже программист должен помнить, сколько максимально бит и там, и там у конкретного сопроцессора, чтобы не потерять данные. ))
Т.е., система команд не зависит от внутреннего представления чисел с плавающей точкой.
В 8086/8087 тоже такой прямой зависимости нет, хотя форматы жестко специфицированы.
Исключение составляют сбросы и обратное чтение файла плавающих регистров в память, где через память ты можешь подглядеть внутреннее представление плавучки.
N>То-то на современных RISC ортогональность по регистрам — почти полная, а вот подставить в любую команду константу или чтение памяти — дзуськи.
Константу легко, с памятью чуть иначе — арифметика, логика и инкремент ячеек памяти невозможны, из памяти можно только читать и писать, бо это так и происходит в проце. ))
Да и это пофик — RISC очень быстро стали суперскалярными (раньше Пентиума), обрабатывающими несколько инструкций за такт, поэтому, разложение одной операции CISC на две операции RISC ничего не ухудшили.
V>>>> усложняло компиляторы, замедляло конечный бинарник множественными пересылками м/у специализированными регистрами,
N>>>Не было там много пересылок, если заранее адекватно распределить регистры.
V>>Да не распределишь ты никак ни ручками, ни компилятором.
V>>Откомпиллируй любой сниппет под 8086 — сплошные mov м/у регистрами.
V>>Сравни с 68k.
N>И снова — боюсь, вопрос в их количестве.
Ес-но, вопрос в относительном количестве межрегистровых mov и парных push/pop.
N>Ну или покажи где это испытать можно. Какой аналог godbolt умеет 8086 и M68k?
Зачем такие сложности? ))
Бери обычный godbolt, посмотри бинарник для MIPS, ARM, Power, сравни с x86 (неважно — MSVC, clang, IC или gcc).
Для перечисленных первых архитектур код будет практически идентичным (с точностью до мнемоник и правил синтаксиса адресации регистров и памяти), а для x86-го будет куча mov и парных push/pop. ))
V>>>> зачастую аж через пары push/pop и т.д. и т.п.
N>>>Это зачем?
V>>А это уже регистров не хватает, их ведь всего 4 якобы общего назначения, а по факту они же безальтернативно дёргаются в целом ряде операций.
N>6. AX, BX, CX, DX, SI, DI. См. выше.
См. на реальный выхлоп компиляторов.
V>>И эти пары push/pop никакое переименование регистров в Pentium-Pro не оптимизирует.
N>Разве?
Конечно.
К стековой памяти может быть внешнее обращение из другого потока, о котором текущий поток может и не знать.
Процессор же не в курсе, что эти парные push/pop породил несчастный компилятор? Это ж, может, так и задумано гениальным программером!
Значит, будет честно исполнять, насилуя оперативку (когерентный кеш, отмечая его невалидность). ))
V>>Сдаётся мне, что дело было только в этом — IBM сделала ставку на невзрачную Intel, бгг...
V>>А та их потом натянула по самые ягодицы... Да и весь мир тоже.
N>Тут таки интересно, почему не сделали для неё однокристальный 360.
Сделали, но позже.
Почему 360? Скорее, 370 и эта однокристалка так и называлась.
У них поколение 370 — изначально практически полная копия 360, но в интегральном исполнении.
Виртуализация, многопроцессорность и прочее — эта разница пошла уже в индексах процов внутри 370-серии (не путать серии машин с сериями процессоров, там другие маркировки), а так-то были варианты машин, представляющие из себя практически тот же 360-й, но на новой элементной базе.
N>С доработкой пары аспектов могла бы чудесно взлететь.
Опоздали! ))
Они явно не ожидали от Intel и MS такой прыти.
Эта сладкая парочка уже зохавала мир и грабила корованы.
Уже не взлетело...
N>По скорости — только потому, что 8086 был спроектирован ужасно и даже NOP занимал 4 такта, а уж что-то сложнее в 10-20 вылезало с ходу. Зато увидев успех, решили исправить узкое место — 286 уже был сильно быстрее.
Ну, дык, я ж и говорю — СССР был вполне себе на уровне.
Т.е. на уровне ведущих мировых производителей.
Проиграл только одному игроку — Intel, ну так ему все проиграли, и на хвалённом капиталистическом Западе все проиграли тоже, бгг...
Может, не в социализме-капитализме было дело?
А в глобализации-империализме? ))
Ведь капитализм не гарантирует империализма без силого давления на другие страны.
Это надо было обеспечить распространение своей продукции без заградительных пошлин, чтобы собрать такой мировой урожай, который собирала Intel.
N>А вот по адресации памяти PDP-11 побить это не могла. DAT в режиме поклейки обоев через замочную скважину — не то, что долго работает. Даже кривоватый 20 бит тут уже лучше.
И то, и то было лишь этапом роста персоналок, поэтому смотрели сквозь пальцы.
Ведь персональные рабочие станции уже существовали и были вполне себе популярны у серьёзных дядек. ))
У MC 68к ведь 32 бита адрес!
В СССР тоже были рабочие станции на основе этого проца.
ИМХО, там было вшивое временное окно буквально в ~5 лет, которое надо было "чем-то заткнуть!", чтобы постепенно дешевеющие 32-адресные (или тру 32-битные процы) попали в персоналки своей ценой.
Но уж заткнули так заткнули...
До сих пор выткнуть сложно. ))
N>>>а вслед взамен VAX, которая была для персоналки слишком дорогая — и ни одного переходного состояния.
V>>Повторюсь, 16 бит выглядели осознанным компромиссом уже тогда, поэтому ведущие игроки планировали будущую жизнь 32 бит.
N>Вот 8086 был чудесным компромиссом с этой точки зрения.
Не так, чтобы чудесным, но да, выглядел компромиссом.
68к был бы лучше...
При том, что IBM позже "осознала косяк" и разработала архитектуру Power в содействии с Motorola, и в системе команд можно уловить много от 68k (хотя это был RISC проц, в отличие от CISC 68k).
Но поезд всё уходил и уходил, набирая обороты... ))
Да, одно время им удавалось немного бодаться...
Но теперь они бодались уже не только и не столько с Intel, сколько с Wintel. ))
По этой причине, гораздо более интересная линейка POWER-процов (серии RS/6000 и выше для серверов, PowerPC для персоналок) глотала за конкурентами пыль.
А DEC Alpha вообще был лебединой песней одного из основоположников современного IT — компании DEC.
А со стороны история Wintel напоминает абсурд из разряда — вы так много продаёте калош, а сшейте нам космический скафандр! ))
V>>В итоге мы всё-равно перешли на серверах опять к UNIX (только уже выращенном изначально на x86-й архитектуре, ес-но!)
N>Сейчас тебе куча народу тут расскажет, где они видели те сервера на UNIx
Linux — всё-равно разновидность Unix.
Изначально это только ядро, весь софт брался готовый.
V>>Во встраиваемой технике каждый третий проц был MIPS (хотя изначально RISC-процессор, но наследник философии VAX и 68к),
N>В чём это он их наследник? У него всё иное.
У него иное только в технологии — это RISC проц.
Просто это уже не тот RISC, которые изпервых самых, как и IBM POWER, там уже нифига не сокращённый набор команд, там просто остутствует микрокод из мира CISC.
Так микрокод и в нынешних x64 процах отсутствует (за исключением особых надобностей в утилитных режимах проца) — в "обычной" работе происходит динамическая перекодировка на подобие RISC.
N>Я бы понял, если бы ты ARM вспомнил — у него хотя бы NZVC и автоинкремент/декремент регистров. Но MIPS — смешно. Это же чистый RISC.
ARM тоже чистый RISC, причём, заметно худший изначально, бо более простой.
Но Айфоны же! ))
Вот MIPS постепенно и сдох, бо ARM получила такой буст денег, что хватило обогнать и перегнать, как грится, превратив изначально убогий RISC в более-менее вменяемый.
У них же система команд тогось, более не ARM, это уже давно совершенно новая система команд, которая со старой имеет из общего лишь часть названия. ))
V>>The Personal/370 was available as early as November 1989
N>На 10 лет позже чем нужно. Я ж говорю — надо было S/360 загнать на одну микруху.
На 8 лет.
И позже оно стало от того, что IBM стала недополучать денег от мейнфреймов из-за популярности IBM/PC и потери монополии.
Им потребовалось срочно модернизировать мейнфреймы, отсюда и появился POWER (на которых до сидит Гугл в своих датацентрах, ктстае, и не жалуется).
N>Вот именно что если добавить A0-A6 для заметной части операций — и получается 15 (я писал 14).
Не, только первые 6.
Там два регистра стека — юзерский и суперпользователя.
N>Много регистров — это много регистров.
Так-то у x86-го в сумме дофига регистров, но код всё-равно корявый из под компиляторов выходит. ))
N>Даже для x86 сделать полноценный OoO стоило настолько дорого, что Intel это осилил только тогда, когда на него свалился дождь золота за ASCI Red.
Дык, я ж и говорю, что все деньги подгребли под себя гаврики без соотв.компетенции:
The first machine to use out-of-order execution was the CDC 6600 (1964)
...
About two years later, the IBM System/360 Model 91 (1966) introduced register renaming with Tomasulo's algorithm,[6] which dissolves false dependencies (WAW and WAR), making full out-of-order execution possible.
N>Это при том, что x86 по сравнению с PDP-11 это полу-RISC в том смысле, что не более одного аргумента в памяти. А вот 68k намеренно накачивали по максимуму CISC-фичами — всеми этими 100500 преавтодекрементными адресациями.
Это легко реализуется и в RISC, бо логика простейшая, что и показал ARM.
Плюс оно же прекрасно обыгрывается не только через OoO, но и через спекулятивное исполнение с отбрасыванием проигравших веток вычислений, как в Эльбрусе.
N>Да, это было сильно позже — последний из 68k общего назначения вышел в 1994. Но мины под будущее были заложены ещё при начальном проектировании.
Да там "мина" была только в том, что Apple проиграла конкуренцию IBM/PC, из-за чего Motorola не имела достаточных денег на дальнейшее развитие среди топа процов.
88k был сырым-провальным.
V>>У нас в ВУЗ-е была машинка с 2 МБ оперативки, а 4 было стандартом во второй половине 70-х.
N>4MB во второй половине 70-х? Не смеши. 256KB, 512KB — верю. 4MB — нет.
У них было.
У нас 2 метра на машинке конца 70-х.
N>К этому уровню модели верхнего уровня у нас дошли лет на 10 позже, как раз ко всеобщему развалу.
Ерунду какую-то говоришь. ))
N>>>(I/D разделение в старших моделях не в счёт, 8086 хотя бы давал сегментные префиксы.)
V>>Что давало ограничение сверху 1 МБ.
N>128KB если один процесс. Ты странно считаешь, мягко говоря.
Ты опять ерунду говоришь, мягко говоря.
Сегментная адресация добавляет 4 разряда к 16-ти.
Я мог адресовать из свой программы ровно 1 метр памяти (если он там был). ))
V>>Это ты уже подзабыл за давностью лет. ))
V>>Если у тебя размер массива был более 64к байт, то начинались пляски с бубном при его итерации и сравнении указателей.
N>И использовать такой массив можно было только в huge модели с huge указателями, а не far.
Не, huge модель тормозила безбожно, и поэтому была практически невостребованной, бо там перевод формата адреса на каждый чих.
Нам хватало 64к элементов массива (и даже намного меньше), но это намного больше 64к байт памяти (хранятся структуры по-значению).
Ссылаться напрямую на элементы (элементы выстроены в двунаправленный граф) — это аж 4 байта, перерасход памяти!
Дешевле было ссылаться по индексу.
Далее.
Итерировать такой массив быстрее всего было ручками, пробегаясь по сегментам и смещениям в двух вложенных циклах.
Я это и имел ввиду — геммор. ))
V>>Проблема была даже в представлении таблицы переходов грамматики — вместо указателей приходилось использовать индексы, чтобы ужаться в 2-байтное представление, из которого каждый божий раз надо было ручками рожать FAR-указатель.
V>>Почему ручками?
Потому что непосредственное манипулирование сегментным регистром и смещением намного эффективнее, чем рождаемый компилятором код из абстрактного исходника.
Собсно, навыки "битовыжимания" шлифовались когда-то из-за угрёбищности x86-й архитектуры. ))
Плюс, компиляторы тех лет давали периодические баги в huge-адресации, мы сотоварищи нашли минимум 3 тогда, избегали определённых конструкций.
V>>Для IBM PC любой из них подошёл бы несравненно лучше.
N>M68k ещё как-то согласен. PDP-11 — нет и нет.
И как же ДВК-3М шла в базе с 248 кб? ))
N>>>Базовые вычислительные операции в 8086 (не 8080) можно было делать между любыми целочисленными регистрами, или ты забыл?
V>>Да какие "любые"? ))
V>>По-факту, в свободном доступе у нас только 4 регистра: A, B, C, D (префиксы-суфиксы E-X опускаю)
N>Я не понимаю, почему ты пропускаешь SI и DI. Это для целочисленных операций полноценные регистры.
Потому что по ним обычно лежит предвычисленное смещение в памяти — вычисления же молотят содержимое памяти...
V>>ОК, готов смириться со специальными индексными, базовым, стековым, но когда многие команды автоматом задевают упомянутые 4 — это уже беспредел.
N>И сколько таких многих?
Это без которых невозможно программировать в любом случае.
V>>По каждой такой команде необходимо помнить, какие регистры она неявно трогает (в каких регистрах надо подготовить данные и откуда потом забирать).
V>>В других асмах неявно дёргается разве что аккумулятор/флаги, остальное указывается явно — код быстро пишется и легко читается .
N>Это уже особенности стиля, да. Я так и не запомнил, где cwd, где cwde (для AT&T — cltq и clto). Лучше бы их писали в стиле <sexti куда, откуда> и <esxto куда, откуда>, даже если куда и откуда фиксированы.
+1
V>>В общем, ASM 8086 — это всегда было отдельной вселенной.
V>>Недостаточно быть "просто крутым ассемблерщиком", надо быть спецом именно по этой архитектуре и... полностью бесполезным для других.
V>>И обратное тоже где-то верно.
N>Нет, общие принципы сохраняются.
Настолько общие, что на практике требуется несколько дней при очередном подходе к 8086-архитектуре, пока опять в памяти всё не уляжется.
Для других архитектур "освежить навыки" — единицы часов или меньше.
Тут м/у языками высокого уровня когда переключаешься — и то порой некоторое время надо на перенастройку...
А там реально, каждый божий раз после некоторого перерыва раз как в новой области себя пробуешь.
Если уж начистоту, то это где-то даже унизительно.
V>>В общем, я что студентом недоумевал/возмущался, что эта кретиническая архитектура постепенно завоёвывает рынок, что сейчас уже машу рукой, но мнение не поменялось, конечно.
N>Я их кретинизм вижу совсем в другом и это не 086, это минимум 286 и дальше.
Ес-но, я говорю о развитии этого всего в 32 бита в i386-м.
Понятно же, что 16 бит были компромиссом сугубо для персоналок, когда в мейнстриме уже лет 20 было 32 бита в мейнфреймах и уже на тот момент в персональных рабочих станциях.
Как компромисс мы бы еще пережили эти вшивые 16 бит, бо им всё-равно уже маячил конец в середине 80-х...
Но они, собаки, сделали аппаратный режим виртуального 8086-го в i386-м, сделав гладкую возможность исполнять накопленное ранее бестолковейшее 16-битное ПО!
Не забудем, не простим! ))
ПО должно переноситься исключительно на уровне исходников, а не бинарников... а то развели бардак, панимашь...
Приучили к плохому...
Вон, в UNIX всё по-уму сделали еще за 10 лет до, POSIX уже закрепился независимо ни от каких операционок, а им подавай бинарную совместимость.
Идиотизм? — очередной он самый.
N>DAT без лёгкого выключения. Безумные шлюзы прерываний. Сегментация внутри виртуального пространства вместо индексации таких пространств (как сделала та же IBM). И т.д. Но уже возможность использовать любой регистр как адресный в 32-битном режиме исправила заметные проблемы.
Но кодировка инструкций доставляла — инструкции по 5-7 байт...
К лопате присобачили кофеварку, рядом садовые ножницы и вот так вырос этот франкенштейн...
Смотреть на это доставляет профессиональную боль...
Понятно же, что начни они разработку с 0-ля, без стремления к унификации с 8086, они бы сделали по-уму...
Но, но...
И эти AMD64 забили последний гвоздь в эту крышку гроба...
Теперь всё, 64 бита уж точно надолго хватит, это не "64к достаточно любой программе".
Т.е., даже в Intel прекрасно осознавали, что они натворили... хотели было исправиться...
А уже фигвам, уже созданные ими же обстоятельства были непреодолимей благородных желаний, бгг...
V>>Сейчас разрабатывать оптимизирующие компиляторы под эту архитектуру стало намного легче, конечно, ведь ADM64 узаконил доп. файл векторных регистров — теперь оптимизирующие компиляторы "почему-то" охотно используют именно их даже не в векторных операциях, бгг...
N>Ну вообще-то SSE предназначен был и для замены x87...
Стандарты SSE опицональны для реализаций x86-совместимых архитектур, AMD тут помог обязаловкой этого файла регистров хотя бы в x64-архитектуре.
ИМХО, им стоило бы сделать маленький шажок — вообще избавиться от унаследованных регистров общего назначения и тупо оставить пару файлов регистров общего назначения, поверх которых теперь есть векторные инструкции.
Я где-то понимаю, что необходимость выполнять в x64 так же 32-битные приложения продиктовали, что ле, некоторую преемственность, но тут нет никаких технических моментов, кроме психологических, ведь эти режимы неодновременны, а внутренний ремаппинг регистров делает фиолетово, как этот регистр называется на ассемблере. ))
А разработанная с 0-ля кодировка инструкций для x64 режима могла бы оботись без того Франкенштейна, который получился из изначально простой лопаты.
Сдаётся мне, что они струхнули сугубо в деле компиляторостроения, боялись, что ниасилят, бо так-то достаточно было подкрутить компилятор gcc x86 в сторону окучивания x64, поменяв совсем немного — только принцип оперирования сегментными регистрами.
N>Сейчас пишут всякие универсальные распределители. И чем бы тут ИИ помог?
В пределе это задача с огромным перебором вариантов, что неприемлимо на практике, бо скорость работы компилятора тоже важна.
ИИ мог бы где-нить в фоне "учиться" на сотнях разновидностей процов одной архитектуры, бесконечно перебирая варианты.
V>>Представь этот же код для 8086 — появятся лишние команды тусования данных по регистрам или в стек и обратно.
N>Представил. Всё равно мало таких операций.
Плохо представил. ))
V>>На PDP-11 и VAX отработали несколько моделей внешних ускорителей с плавучкой — система команд никак не влияла на представление плавучки.
V>>И именно DEC явился тем полигоном, на которых эти форматы были испробованы/отработаны и закреплены в международных стандартах.
N>IEEE был отработан на DEC? Дай ссылку.
IEEE был зафиксирован вовсе не в DEC, просто для одной и той же архитектуры DEC шли различные варианты блока вычислений с плавающей точкой с различным представлениями и правилами оперирования. Некоторые из вариантов поддерживали IEEE-784 задолго до появления этого стандарта. ))
V>>Сейчас ведь уже легко ответить на вопрос, что лучше — "отлитая из бетона" плавучка в IBM 360/370, или "оставленная на выяснение по ходу пьесы" модель PDP-11/VAX?
N>Что там могли оставить на выяснение, если для конкретной команды формат был фиксирован?
Само представление числа с плавающей точкой и правила работы с ним не были фиксированы.
Это были просто инструкции, которые генерировали определённые наборы сигналов в управляющей схеме, к которой подключался незавимиый модуль вычислений с плавающей точкой.
Это почему DEC-компьютеры можно было модернизировать в том числе повышая им производительность в плавучке, а в случае IBM 360/370 модернизация касалась только размера оперативки и периферии.
V>>Принятый в IBM 360/370 формат и соотв. правила оперирования им уступали более поздним разработкам, но!
V>>Система команд IBM 360/370 никак не опиралась на формат плавучки, т.е. этот формат мог быть доработан позже, а программы пересобраны из исходников.
N>См. выше.
На что смотреть?
Формат плавучки для IBM 360 найти легко. ))
N>И что значит "никак не опиралась" при наличии, например, ненормализующих команд?
Так а что эти команды меняют в бинарнике?
Для модульной архитектуры команда означала выдачу определённого кода на внешний сопроцессор, а для "литой" архитектуры IBM 360 — "что-то происходит с регистром".
Даже приведение к целому и обратно — этим занимается сопроцессор.
Команды — разложить на порядок и мантису или собрать обратно — аналогично.
Тут уже программист должен помнить, сколько максимально бит и там, и там у конкретного сопроцессора, чтобы не потерять данные. ))
Т.е., система команд не зависит от внутреннего представления чисел с плавающей точкой.
В 8086/8087 тоже такой прямой зависимости нет, хотя форматы жестко специфицированы.
Исключение составляют сбросы и обратное чтение файла плавающих регистров в память, где через память ты можешь подглядеть внутреннее представление плавучки.
N>То-то на современных RISC ортогональность по регистрам — почти полная, а вот подставить в любую команду константу или чтение памяти — дзуськи.
Константу легко, с памятью чуть иначе — арифметика, логика и инкремент ячеек памяти невозможны, из памяти можно только читать и писать, бо это так и происходит в проце. ))
Да и это пофик — RISC очень быстро стали суперскалярными (раньше Пентиума), обрабатывающими несколько инструкций за такт, поэтому, разложение одной операции CISC на две операции RISC ничего не ухудшили.
V>>>> усложняло компиляторы, замедляло конечный бинарник множественными пересылками м/у специализированными регистрами,
N>>>Не было там много пересылок, если заранее адекватно распределить регистры.
V>>Да не распределишь ты никак ни ручками, ни компилятором.
V>>Откомпиллируй любой сниппет под 8086 — сплошные mov м/у регистрами.
V>>Сравни с 68k.
N>И снова — боюсь, вопрос в их количестве.
Ес-но, вопрос в относительном количестве межрегистровых mov и парных push/pop.
N>Ну или покажи где это испытать можно. Какой аналог godbolt умеет 8086 и M68k?
Зачем такие сложности? ))
Бери обычный godbolt, посмотри бинарник для MIPS, ARM, Power, сравни с x86 (неважно — MSVC, clang, IC или gcc).
#include <iostream>
int main() {
int a;
std::cin >> a;
int b;
std::cin >> b;
int c;
std::cin >> c;
std::cout << ((a/b)^c*a/b);
}Для перечисленных первых архитектур код будет практически идентичным (с точностью до мнемоник и правил синтаксиса адресации регистров и памяти), а для x86-го будет куча mov и парных push/pop. ))
V>>>> зачастую аж через пары push/pop и т.д. и т.п.
N>>>Это зачем?
V>>А это уже регистров не хватает, их ведь всего 4 якобы общего назначения, а по факту они же безальтернативно дёргаются в целом ряде операций.
N>6. AX, BX, CX, DX, SI, DI. См. выше.
См. на реальный выхлоп компиляторов.
V>>И эти пары push/pop никакое переименование регистров в Pentium-Pro не оптимизирует.
N>Разве?
Конечно.
К стековой памяти может быть внешнее обращение из другого потока, о котором текущий поток может и не знать.
Процессор же не в курсе, что эти парные push/pop породил несчастный компилятор? Это ж, может, так и задумано гениальным программером!
Значит, будет честно исполнять, насилуя оперативку (когерентный кеш, отмечая его невалидность). ))
V>>Сдаётся мне, что дело было только в этом — IBM сделала ставку на невзрачную Intel, бгг...
V>>А та их потом натянула по самые ягодицы... Да и весь мир тоже.
N>Тут таки интересно, почему не сделали для неё однокристальный 360.
Сделали, но позже.
Почему 360? Скорее, 370 и эта однокристалка так и называлась.
У них поколение 370 — изначально практически полная копия 360, но в интегральном исполнении.
Виртуализация, многопроцессорность и прочее — эта разница пошла уже в индексах процов внутри 370-серии (не путать серии машин с сериями процессоров, там другие маркировки), а так-то были варианты машин, представляющие из себя практически тот же 360-й, но на новой элементной базе.
N>С доработкой пары аспектов могла бы чудесно взлететь.
Опоздали! ))
Они явно не ожидали от Intel и MS такой прыти.
Эта сладкая парочка уже зохавала мир и грабила корованы.
Уже не взлетело...
N>По скорости — только потому, что 8086 был спроектирован ужасно и даже NOP занимал 4 такта, а уж что-то сложнее в 10-20 вылезало с ходу. Зато увидев успех, решили исправить узкое место — 286 уже был сильно быстрее.
Ну, дык, я ж и говорю — СССР был вполне себе на уровне.
Т.е. на уровне ведущих мировых производителей.
Проиграл только одному игроку — Intel, ну так ему все проиграли, и на хвалённом капиталистическом Западе все проиграли тоже, бгг...
Может, не в социализме-капитализме было дело?
А в глобализации-империализме? ))
Ведь капитализм не гарантирует империализма без силого давления на другие страны.
Это надо было обеспечить распространение своей продукции без заградительных пошлин, чтобы собрать такой мировой урожай, который собирала Intel.
N>А вот по адресации памяти PDP-11 побить это не могла. DAT в режиме поклейки обоев через замочную скважину — не то, что долго работает. Даже кривоватый 20 бит тут уже лучше.
И то, и то было лишь этапом роста персоналок, поэтому смотрели сквозь пальцы.
Ведь персональные рабочие станции уже существовали и были вполне себе популярны у серьёзных дядек. ))
У MC 68к ведь 32 бита адрес!
В СССР тоже были рабочие станции на основе этого проца.
ИМХО, там было вшивое временное окно буквально в ~5 лет, которое надо было "чем-то заткнуть!", чтобы постепенно дешевеющие 32-адресные (или тру 32-битные процы) попали в персоналки своей ценой.
Но уж заткнули так заткнули...
До сих пор выткнуть сложно. ))
N>>>а вслед взамен VAX, которая была для персоналки слишком дорогая — и ни одного переходного состояния.
V>>Повторюсь, 16 бит выглядели осознанным компромиссом уже тогда, поэтому ведущие игроки планировали будущую жизнь 32 бит.
N>Вот 8086 был чудесным компромиссом с этой точки зрения.
Не так, чтобы чудесным, но да, выглядел компромиссом.
68к был бы лучше...
При том, что IBM позже "осознала косяк" и разработала архитектуру Power в содействии с Motorola, и в системе команд можно уловить много от 68k (хотя это был RISC проц, в отличие от CISC 68k).
Но поезд всё уходил и уходил, набирая обороты... ))
Да, одно время им удавалось немного бодаться...
Но теперь они бодались уже не только и не столько с Intel, сколько с Wintel. ))
По этой причине, гораздо более интересная линейка POWER-процов (серии RS/6000 и выше для серверов, PowerPC для персоналок) глотала за конкурентами пыль.
А DEC Alpha вообще был лебединой песней одного из основоположников современного IT — компании DEC.
А со стороны история Wintel напоминает абсурд из разряда — вы так много продаёте калош, а сшейте нам космический скафандр! ))
V>>В итоге мы всё-равно перешли на серверах опять к UNIX (только уже выращенном изначально на x86-й архитектуре, ес-но!)
N>Сейчас тебе куча народу тут расскажет, где они видели те сервера на UNIx
Linux — всё-равно разновидность Unix.
Изначально это только ядро, весь софт брался готовый.
GNU — операционная система типа Unix
V>>Во встраиваемой технике каждый третий проц был MIPS (хотя изначально RISC-процессор, но наследник философии VAX и 68к),
N>В чём это он их наследник? У него всё иное.
У него иное только в технологии — это RISC проц.
Просто это уже не тот RISC, которые изпервых самых, как и IBM POWER, там уже нифига не сокращённый набор команд, там просто остутствует микрокод из мира CISC.
Так микрокод и в нынешних x64 процах отсутствует (за исключением особых надобностей в утилитных режимах проца) — в "обычной" работе происходит динамическая перекодировка на подобие RISC.
N>Я бы понял, если бы ты ARM вспомнил — у него хотя бы NZVC и автоинкремент/декремент регистров. Но MIPS — смешно. Это же чистый RISC.
ARM тоже чистый RISC, причём, заметно худший изначально, бо более простой.
Но Айфоны же! ))
Вот MIPS постепенно и сдох, бо ARM получила такой буст денег, что хватило обогнать и перегнать, как грится, превратив изначально убогий RISC в более-менее вменяемый.
У них же система команд тогось, более не ARM, это уже давно совершенно новая система команд, которая со старой имеет из общего лишь часть названия. ))
V>>The Personal/370 was available as early as November 1989
N>На 10 лет позже чем нужно. Я ж говорю — надо было S/360 загнать на одну микруху.
На 8 лет.
И позже оно стало от того, что IBM стала недополучать денег от мейнфреймов из-за популярности IBM/PC и потери монополии.
Им потребовалось срочно модернизировать мейнфреймы, отсюда и появился POWER (на которых до сидит Гугл в своих датацентрах, ктстае, и не жалуется).
N>Вот именно что если добавить A0-A6 для заметной части операций — и получается 15 (я писал 14).
Не, только первые 6.
Там два регистра стека — юзерский и суперпользователя.
N>Много регистров — это много регистров.
Так-то у x86-го в сумме дофига регистров, но код всё-равно корявый из под компиляторов выходит. ))
Re[6]: История компьютеров в СССР
Здравствуйте, netch80, Вы писали:
N>Даже для x86 сделать полноценный OoO стоило настолько дорого, что Intel это осилил только тогда, когда на него свалился дождь золота за ASCI Red.
Дык, я ж и говорю, что все деньги подгребли под себя гаврики без соотв.компетенции:
N>Это при том, что x86 по сравнению с PDP-11 это полу-RISC в том смысле, что не более одного аргумента в памяти. А вот 68k намеренно накачивали по максимуму CISC-фичами — всеми этими 100500 преавтодекрементными адресациями.
Это легко реализуется и в RISC, бо логика простейшая, что и показал ARM.
Плюс оно же прекрасно обыгрывается не только через OoO, но и через спекулятивное исполнение с отбрасыванием проигравших веток вычислений, как в Эльбрусе.
N>Да, это было сильно позже — последний из 68k общего назначения вышел в 1994. Но мины под будущее были заложены ещё при начальном проектировании.
Да там "мина" была только в том, что Apple проиграла конкуренцию IBM/PC, из-за чего Motorola не имела достаточных денег на дальнейшее развитие среди топа процов.
88k был сырым-провальным.
V>>У нас в ВУЗ-е была машинка с 2 МБ оперативки, а 4 было стандартом во второй половине 70-х.
N>4MB во второй половине 70-х? Не смеши. 256KB, 512KB — верю. 4MB — нет.
У них было.
У нас 2 метра на машинке конца 70-х.
N>К этому уровню модели верхнего уровня у нас дошли лет на 10 позже, как раз ко всеобщему развалу.
Ерунду какую-то говоришь. ))
N>>>(I/D разделение в старших моделях не в счёт, 8086 хотя бы давал сегментные префиксы.)
V>>Что давало ограничение сверху 1 МБ.
N>128KB если один процесс. Ты странно считаешь, мягко говоря.
Ты опять ерунду говоришь, мягко говоря.
Сегментная адресация добавляет 4 разряда к 16-ти.
Я мог адресовать из свой программы ровно 1 метр памяти (если он там был). ))
V>>Это ты уже подзабыл за давностью лет. ))
V>>Если у тебя размер массива был более 64к байт, то начинались пляски с бубном при его итерации и сравнении указателей.
N>И использовать такой массив можно было только в huge модели с huge указателями, а не far.
Не, huge модель тормозила безбожно, и поэтому была практически невостребованной, бо там перевод формата адреса на каждый чих.
Нам хватало 64к элементов массива (и даже намного меньше), но это намного больше 64к байт памяти (хранятся структуры по-значению).
Ссылаться напрямую на элементы (элементы выстроены в двунаправленный граф) — это аж 4 байта, перерасход памяти!
Дешевле было ссылаться по индексу.
Далее.
Итерировать такой массив быстрее всего было ручками, пробегаясь по сегментам и смещениям в двух вложенных циклах.
Я это и имел ввиду — геммор. ))
V>>Проблема была даже в представлении таблицы переходов грамматики — вместо указателей приходилось использовать индексы, чтобы ужаться в 2-байтное представление, из которого каждый божий раз надо было ручками рожать FAR-указатель.
V>>Почему ручками?
Потому что непосредственное манипулирование сегментным регистром и смещением намного эффективнее, чем рождаемый компилятором код из абстрактного исходника.
Собсно, навыки "битовыжимания" шлифовались когда-то из-за угрёбищности x86-й архитектуры. ))
Плюс, компиляторы тех лет давали периодические баги в huge-адресации, мы сотоварищи нашли минимум 3 тогда, избегали определённых конструкций.
V>>Для IBM PC любой из них подошёл бы несравненно лучше.
N>M68k ещё как-то согласен. PDP-11 — нет и нет.
И как же ДВК-3М шла в базе с 248 кб? ))
N>>>Базовые вычислительные операции в 8086 (не 8080) можно было делать между любыми целочисленными регистрами, или ты забыл?
V>>Да какие "любые"? ))
V>>По-факту, в свободном доступе у нас только 4 регистра: A, B, C, D (префиксы-суфиксы E-X опускаю)
N>Я не понимаю, почему ты пропускаешь SI и DI. Это для целочисленных операций полноценные регистры.
Потому что по ним обычно лежит предвычисленное смещение в памяти — вычисления же молотят содержимое памяти...
V>>ОК, готов смириться со специальными индексными, базовым, стековым, но когда многие команды автоматом задевают упомянутые 4 — это уже беспредел.
N>И сколько таких многих?
Это без которых невозможно программировать в любом случае.
V>>По каждой такой команде необходимо помнить, какие регистры она неявно трогает (в каких регистрах надо подготовить данные и откуда потом забирать).
V>>В других асмах неявно дёргается разве что аккумулятор/флаги, остальное указывается явно — код быстро пишется и легко читается .
N>Это уже особенности стиля, да. Я так и не запомнил, где cwd, где cwde (для AT&T — cltq и clto). Лучше бы их писали в стиле <sexti куда, откуда> и <esxto куда, откуда>, даже если куда и откуда фиксированы.
+1
V>>В общем, ASM 8086 — это всегда было отдельной вселенной.
V>>Недостаточно быть "просто крутым ассемблерщиком", надо быть спецом именно по этой архитектуре и... полностью бесполезным для других.
V>>И обратное тоже где-то верно.
N>Нет, общие принципы сохраняются.
Настолько общие, что на практике требуется несколько дней при очередном подходе к 8086-архитектуре, пока опять в памяти всё не уляжется.
Для других архитектур "освежить навыки" — единицы часов или меньше.
Тут м/у языками высокого уровня когда переключаешься — и то порой некоторое время надо на перенастройку...
А там реально, каждый божий раз после некоторого перерыва раз как в новой области себя пробуешь.
Если уж начистоту, то это где-то даже унизительно.
V>>В общем, я что студентом недоумевал/возмущался, что эта кретиническая архитектура постепенно завоёвывает рынок, что сейчас уже машу рукой, но мнение не поменялось, конечно.
N>Я их кретинизм вижу совсем в другом и это не 086, это минимум 286 и дальше.
Ес-но, я говорю о развитии этого всего в 32 бита в i386-м.
Понятно же, что 16 бит были компромиссом сугубо для персоналок, когда в мейнстриме уже лет 20 было 32 бита в мейнфреймах и уже на тот момент в персональных рабочих станциях.
Как компромисс мы бы еще пережили эти вшивые 16 бит, бо им всё-равно уже маячил конец в середине 80-х...
Но они, собаки, сделали аппаратный режим виртуального 8086-го в i386-м, сделав гладкую возможность исполнять накопленное ранее бестолковейшее 16-битное ПО!
Не забудем, не простим! ))
ПО должно переноситься исключительно на уровне исходников, а не бинарников... а то развели бардак, панимашь...
Приучили к плохому...
Вон, в UNIX всё по-уму сделали еще за 10 лет до, POSIX уже закрепился независимо ни от каких операционок, а им подавай бинарную совместимость.
Идиотизм? — очередной он самый.
N>DAT без лёгкого выключения. Безумные шлюзы прерываний. Сегментация внутри виртуального пространства вместо индексации таких пространств (как сделала та же IBM). И т.д. Но уже возможность использовать любой регистр как адресный в 32-битном режиме исправила заметные проблемы.
Но кодировка инструкций доставляла — инструкции по 5-7 байт...
К лопате присобачили кофеварку, рядом садовые ножницы и вот так вырос этот франкенштейн...
Смотреть на это доставляет профессиональную боль...
Понятно же, что начни они разработку с 0-ля, без стремления к унификации с 8086, они бы сделали по-уму...
Но, но...
И эти AMD64 забили последний гвоздь в эту крышку гроба...
Теперь всё, 64 бита уж точно надолго хватит, это не "64к достаточно любой программе".
Т.е., даже в Intel прекрасно осознавали, что они натворили... хотели было исправиться...
А уже фигвам, уже созданные ими же обстоятельства были непреодолимей благородных желаний, бгг...
V>>Сейчас разрабатывать оптимизирующие компиляторы под эту архитектуру стало намного легче, конечно, ведь ADM64 узаконил доп. файл векторных регистров — теперь оптимизирующие компиляторы "почему-то" охотно используют именно их даже не в векторных операциях, бгг...
N>Ну вообще-то SSE предназначен был и для замены x87...
Стандарты SSE опицональны для реализаций x86-совместимых архитектур, AMD тут помог обязаловкой этого файла регистров хотя бы в x64-архитектуре.
ИМХО, им стоило бы сделать маленький шажок — вообще избавиться от унаследованных регистров общего назначения и тупо оставить пару файлов регистров общего назначения, поверх которых теперь есть векторные инструкции.
Я где-то понимаю, что необходимость выполнять в x64 так же 32-битные приложения продиктовали, что ле, некоторую преемственность, но тут нет никаких технических моментов, кроме психологических, ведь эти режимы неодновременны, а внутренний ремаппинг регистров делает фиолетово, как этот регистр называется на ассемблере. ))
А разработанная с 0-ля кодировка инструкций для x64 режима могла бы оботись без того Франкенштейна, который получился из изначально простой лопаты.
Сдаётся мне, что они струхнули сугубо в деле компиляторостроения, боялись, что ниасилят, бо так-то достаточно было подкрутить компилятор gcc x86 в сторону окучивания x64, поменяв совсем немного — только принцип оперирования сегментными регистрами.
N>Сейчас пишут всякие универсальные распределители. И чем бы тут ИИ помог?
В пределе это задача с огромным перебором вариантов, что неприемлимо на практике, бо скорость работы компилятора тоже важна.
ИИ мог бы где-нить в фоне "учиться" на сотнях разновидностей процов одной архитектуры, бесконечно перебирая варианты.
V>>Представь этот же код для 8086 — появятся лишние команды тусования данных по регистрам или в стек и обратно.
N>Представил. Всё равно мало таких операций.
Плохо представил. ))
V>>На PDP-11 и VAX отработали несколько моделей внешних ускорителей с плавучкой — система команд никак не влияла на представление плавучки.
V>>И именно DEC явился тем полигоном, на которых эти форматы были испробованы/отработаны и закреплены в международных стандартах.
N>IEEE был отработан на DEC? Дай ссылку.
IEEE был зафиксирован вовсе не в DEC, просто для одной и той же архитектуры DEC шли различные варианты блока вычислений с плавающей точкой с различным представлениями и правилами оперирования. Некоторые из вариантов поддерживали IEEE-784 задолго до появления этого стандарта. ))
V>>Сейчас ведь уже легко ответить на вопрос, что лучше — "отлитая из бетона" плавучка в IBM 360/370, или "оставленная на выяснение по ходу пьесы" модель PDP-11/VAX?
N>Что там могли оставить на выяснение, если для конкретной команды формат был фиксирован?
Само представление числа с плавающей точкой и правила работы с ним не были фиксированы.
Это были просто инструкции, которые генерировали определённые наборы сигналов в управляющей схеме, к которой подключался незавимиый модуль вычислений с плавающей точкой.
Это почему DEC-компьютеры можно было модернизировать в том числе повышая им производительность в плавучке, а в случае IBM 360/370 модернизация касалась только размера оперативки и периферии.
V>>Принятый в IBM 360/370 формат и соотв. правила оперирования им уступали более поздним разработкам, но!
V>>Система команд IBM 360/370 никак не опиралась на формат плавучки, т.е. этот формат мог быть доработан позже, а программы пересобраны из исходников.
N>См. выше.
На что смотреть?
Формат плавучки для IBM 360 найти легко. ))
N>И что значит "никак не опиралась" при наличии, например, ненормализующих команд?
Так а что эти команды меняют в бинарнике?
Для модульной архитектуры команда означала выдачу определённого кода на внешний сопроцессор, а для "литой" архитектуры IBM 360 — "что-то происходит с регистром".
Даже приведение к целому и обратно — этим занимается сопроцессор.
Команды — разложить на порядок и мантису или собрать обратно — аналогично.
Тут уже программист должен помнить, сколько максимально бит и там, и там у конкретного сопроцессора, чтобы не потерять данные. ))
Т.е., система команд не зависит от внутреннего представления чисел с плавающей точкой.
В 8086/8087 тоже такой прямой зависимости нет, хотя форматы жестко специфицированы.
Исключение составляют сбросы и обратное чтение файла плавающих регистров в память, где через память ты можешь подглядеть внутреннее представление плавучки.
N>То-то на современных RISC ортогональность по регистрам — почти полная, а вот подставить в любую команду константу или чтение памяти — дзуськи.
Константу легко, с памятью чуть иначе — арифметика, логика и инкремент ячеек памяти невозможны, из памяти можно только читать и писать, бо это так и происходит в проце. ))
Да и это пофик — RISC очень быстро стали суперскалярными (раньше Пентиума), обрабатывающими несколько инструкций за такт, поэтому, разложение одной операции CISC на две операции RISC ничего не ухудшили.
V>>>> усложняло компиляторы, замедляло конечный бинарник множественными пересылками м/у специализированными регистрами,
N>>>Не было там много пересылок, если заранее адекватно распределить регистры.
V>>Да не распределишь ты никак ни ручками, ни компилятором.
V>>Откомпиллируй любой сниппет под 8086 — сплошные mov м/у регистрами.
V>>Сравни с 68k.
N>И снова — боюсь, вопрос в их количестве.
Ес-но, вопрос в относительном количестве межрегистровых mov и парных push/pop.
N>Ну или покажи где это испытать можно. Какой аналог godbolt умеет 8086 и M68k?
Зачем такие сложности? ))
Бери обычный godbolt, посмотри бинарник для MIPS, ARM, Power, сравни с x86 (неважно — MSVC, clang, IC или gcc).
Для перечисленных первых архитектур код будет практически идентичным (с точностью до мнемоник и правил синтаксиса адресации регистров и памяти), а для x86-го будет куча mov и парных push/pop. ))
V>>>> зачастую аж через пары push/pop и т.д. и т.п.
N>>>Это зачем?
V>>А это уже регистров не хватает, их ведь всего 4 якобы общего назначения, а по факту они же безальтернативно дёргаются в целом ряде операций.
N>6. AX, BX, CX, DX, SI, DI. См. выше.
См. на реальный выхлоп компиляторов.
V>>И эти пары push/pop никакое переименование регистров в Pentium-Pro не оптимизирует.
N>Разве?
Конечно.
К стековой памяти может быть внешнее обращение из другого потока, о котором текущий поток может и не знать.
Процессор же не в курсе, что эти парные push/pop породил несчастный компилятор? Это ж, может, так и задумано гениальным программером!
Значит, будет честно исполнять, насилуя оперативку (когерентный кеш, отмечая его невалидность). ))
V>>Сдаётся мне, что дело было только в этом — IBM сделала ставку на невзрачную Intel, бгг...
V>>А та их потом натянула по самые ягодицы... Да и весь мир тоже.
N>Тут таки интересно, почему не сделали для неё однокристальный 360.
Сделали, но позже.
Почему 360? Скорее, 370 и эта однокристалка так и называлась.
У них поколение 370 — изначально практически полная копия 360, но в интегральном исполнении.
Виртуализация, многопроцессорность и прочее — эта разница пошла уже в индексах процов внутри 370-серии (не путать серии машин с сериями процессоров, там другие маркировки), а так-то были варианты машин, представляющие из себя практически тот же 360-й, но на новой элементной базе.
N>С доработкой пары аспектов могла бы чудесно взлететь.
Опоздали! ))
Они явно не ожидали от Intel и MS такой прыти.
Эта сладкая парочка уже зохавала мир и грабила корованы.
Уже не взлетело...
N>По скорости — только потому, что 8086 был спроектирован ужасно и даже NOP занимал 4 такта, а уж что-то сложнее в 10-20 вылезало с ходу. Зато увидев успех, решили исправить узкое место — 286 уже был сильно быстрее.
Ну, дык, я ж и говорю — СССР был вполне себе на уровне.
Т.е. на уровне ведущих мировых производителей.
Проиграл только одному игроку — Intel, ну так ему все проиграли, и на хвалённом капиталистическом Западе все проиграли тоже, бгг...
Может, не в социализме-капитализме было дело?
А в глобализации-империализме? ))
Ведь капитализм не гарантирует империализма без силого давления на другие страны.
Это надо было обеспечить распространение своей продукции без заградительных пошлин, чтобы собрать такой мировой урожай, который собирала Intel.
N>А вот по адресации памяти PDP-11 побить это не могла. DAT в режиме поклейки обоев через замочную скважину — не то, что долго работает. Даже кривоватый 20 бит тут уже лучше.
И то, и то было лишь этапом роста персоналок, поэтому смотрели сквозь пальцы.
Ведь персональные рабочие станции уже существовали и были вполне себе популярны у серьёзных дядек. ))
У MC 68к ведь 32 бита адрес!
В СССР тоже были рабочие станции на основе этого проца.
ИМХО, там было вшивое временное окно буквально в ~5 лет, которое надо было "чем-то заткнуть!", чтобы постепенно дешевеющие 32-адресные (или тру 32-битные процы) попали в персоналки своей ценой.
Но уж заткнули так заткнули...
До сих пор выткнуть сложно. ))
N>>>а вслед взамен VAX, которая была для персоналки слишком дорогая — и ни одного переходного состояния.
V>>Повторюсь, 16 бит выглядели осознанным компромиссом уже тогда, поэтому ведущие игроки планировали будущую жизнь 32 бит.
N>Вот 8086 был чудесным компромиссом с этой точки зрения.
Не так, чтобы чудесным, но да, выглядел компромиссом.
68к был бы лучше...
При том, что IBM позже "осознала косяк" и разработала архитектуру Power в содействии с Motorola, и в системе команд можно уловить много от 68k (хотя это был RISC проц, в отличие от CISC 68k).
Но поезд всё уходил и уходил, набирая обороты... ))
Да, одно время им удавалось немного бодаться...
Но теперь они бодались уже не только и не столько с Intel, сколько с Wintel. ))
По этой причине, гораздо более интересная линейка POWER-процов (серии RS/6000 и выше для серверов, PowerPC для персоналок) глотала за конкурентами пыль.
А DEC Alpha вообще был лебединой песней одного из основоположников современного IT — компании DEC.
А со стороны история Wintel напоминает абсурд из разряда — вы так много продаёте калош, а сшейте нам космический скафандр! ))
V>>В итоге мы всё-равно перешли на серверах опять к UNIX (только уже выращенном изначально на x86-й архитектуре, ес-но!)
N>Сейчас тебе куча народу тут расскажет, где они видели те сервера на UNIx
Linux — всё-равно разновидность Unix.
Изначально это только ядро, весь софт брался готовый.
V>>Во встраиваемой технике каждый третий проц был MIPS (хотя изначально RISC-процессор, но наследник философии VAX и 68к),
N>В чём это он их наследник? У него всё иное.
У него иное только в технологии — это RISC проц.
Просто это уже не тот RISC, которые изпервых самых, как и IBM POWER, там уже нифига не сокращённый набор команд, там просто остутствует микрокод из мира CISC.
Так микрокод и в нынешних x64 процах отсутствует (за исключением особых надобностей в утилитных режимах проца) — в "обычной" работе происходит динамическая перекодировка на подобие RISC.
N>Я бы понял, если бы ты ARM вспомнил — у него хотя бы NZVC и автоинкремент/декремент регистров. Но MIPS — смешно. Это же чистый RISC.
ARM тоже чистый RISC, причём, заметно худший изначально, бо более простой.
Но Айфоны же! ))
Вот MIPS постепенно и сдох, бо ARM получила такой буст денег, что хватило обогнать и перегнать, как грится, превратив изначально убогий RISC в более-менее вменяемый.
У них же система команд тогось, более не ARM, это уже давно совершенно новая система команд, которая со старой имеет из общего лишь часть названия. ))
V>>The Personal/370 was available as early as November 1989
N>На 10 лет позже чем нужно. Я ж говорю — надо было S/360 загнать на одну микруху.
На 8 лет.
И позже оно стало от того, что IBM стала недополучать денег от мейнфреймов из-за популярности IBM/PC и потери монополии.
Им потребовалось срочно модернизировать мейнфреймы, отсюда и появился POWER (на которых до сих пор сидит Гугл в своих датацентрах, ктстае, и не жалуется).
N>Вот именно что если добавить A0-A6 для заметной части операций — и получается 15 (я писал 14).
Не, только первые 6.
Там два регистра стека — юзерский и суперпользователя.
N>Много регистров — это много регистров.
Так-то у x86-го в сумме дофига регистров, но код всё-равно корявый из под компиляторов выходит. ))
N>Даже для x86 сделать полноценный OoO стоило настолько дорого, что Intel это осилил только тогда, когда на него свалился дождь золота за ASCI Red.
Дык, я ж и говорю, что все деньги подгребли под себя гаврики без соотв.компетенции:
The first machine to use out-of-order execution was the CDC 6600 (1964)
...
About two years later, the IBM System/360 Model 91 (1966) introduced register renaming with Tomasulo's algorithm,[6] which dissolves false dependencies (WAW and WAR), making full out-of-order execution possible.
N>Это при том, что x86 по сравнению с PDP-11 это полу-RISC в том смысле, что не более одного аргумента в памяти. А вот 68k намеренно накачивали по максимуму CISC-фичами — всеми этими 100500 преавтодекрементными адресациями.
Это легко реализуется и в RISC, бо логика простейшая, что и показал ARM.
Плюс оно же прекрасно обыгрывается не только через OoO, но и через спекулятивное исполнение с отбрасыванием проигравших веток вычислений, как в Эльбрусе.
N>Да, это было сильно позже — последний из 68k общего назначения вышел в 1994. Но мины под будущее были заложены ещё при начальном проектировании.
Да там "мина" была только в том, что Apple проиграла конкуренцию IBM/PC, из-за чего Motorola не имела достаточных денег на дальнейшее развитие среди топа процов.
88k был сырым-провальным.
V>>У нас в ВУЗ-е была машинка с 2 МБ оперативки, а 4 было стандартом во второй половине 70-х.
N>4MB во второй половине 70-х? Не смеши. 256KB, 512KB — верю. 4MB — нет.
У них было.
У нас 2 метра на машинке конца 70-х.
N>К этому уровню модели верхнего уровня у нас дошли лет на 10 позже, как раз ко всеобщему развалу.
Ерунду какую-то говоришь. ))
N>>>(I/D разделение в старших моделях не в счёт, 8086 хотя бы давал сегментные префиксы.)
V>>Что давало ограничение сверху 1 МБ.
N>128KB если один процесс. Ты странно считаешь, мягко говоря.
Ты опять ерунду говоришь, мягко говоря.
Сегментная адресация добавляет 4 разряда к 16-ти.
Я мог адресовать из свой программы ровно 1 метр памяти (если он там был). ))
V>>Это ты уже подзабыл за давностью лет. ))
V>>Если у тебя размер массива был более 64к байт, то начинались пляски с бубном при его итерации и сравнении указателей.
N>И использовать такой массив можно было только в huge модели с huge указателями, а не far.
Не, huge модель тормозила безбожно, и поэтому была практически невостребованной, бо там перевод формата адреса на каждый чих.
Нам хватало 64к элементов массива (и даже намного меньше), но это намного больше 64к байт памяти (хранятся структуры по-значению).
Ссылаться напрямую на элементы (элементы выстроены в двунаправленный граф) — это аж 4 байта, перерасход памяти!
Дешевле было ссылаться по индексу.
Далее.
Итерировать такой массив быстрее всего было ручками, пробегаясь по сегментам и смещениям в двух вложенных циклах.
Я это и имел ввиду — геммор. ))
V>>Проблема была даже в представлении таблицы переходов грамматики — вместо указателей приходилось использовать индексы, чтобы ужаться в 2-байтное представление, из которого каждый божий раз надо было ручками рожать FAR-указатель.
V>>Почему ручками?
Потому что непосредственное манипулирование сегментным регистром и смещением намного эффективнее, чем рождаемый компилятором код из абстрактного исходника.
Собсно, навыки "битовыжимания" шлифовались когда-то из-за угрёбищности x86-й архитектуры. ))
Плюс, компиляторы тех лет давали периодические баги в huge-адресации, мы сотоварищи нашли минимум 3 тогда, избегали определённых конструкций.
V>>Для IBM PC любой из них подошёл бы несравненно лучше.
N>M68k ещё как-то согласен. PDP-11 — нет и нет.
И как же ДВК-3М шла в базе с 248 кб? ))
N>>>Базовые вычислительные операции в 8086 (не 8080) можно было делать между любыми целочисленными регистрами, или ты забыл?
V>>Да какие "любые"? ))
V>>По-факту, в свободном доступе у нас только 4 регистра: A, B, C, D (префиксы-суфиксы E-X опускаю)
N>Я не понимаю, почему ты пропускаешь SI и DI. Это для целочисленных операций полноценные регистры.
Потому что по ним обычно лежит предвычисленное смещение в памяти — вычисления же молотят содержимое памяти...
V>>ОК, готов смириться со специальными индексными, базовым, стековым, но когда многие команды автоматом задевают упомянутые 4 — это уже беспредел.
N>И сколько таких многих?
Это без которых невозможно программировать в любом случае.
V>>По каждой такой команде необходимо помнить, какие регистры она неявно трогает (в каких регистрах надо подготовить данные и откуда потом забирать).
V>>В других асмах неявно дёргается разве что аккумулятор/флаги, остальное указывается явно — код быстро пишется и легко читается .
N>Это уже особенности стиля, да. Я так и не запомнил, где cwd, где cwde (для AT&T — cltq и clto). Лучше бы их писали в стиле <sexti куда, откуда> и <esxto куда, откуда>, даже если куда и откуда фиксированы.
+1
V>>В общем, ASM 8086 — это всегда было отдельной вселенной.
V>>Недостаточно быть "просто крутым ассемблерщиком", надо быть спецом именно по этой архитектуре и... полностью бесполезным для других.
V>>И обратное тоже где-то верно.
N>Нет, общие принципы сохраняются.
Настолько общие, что на практике требуется несколько дней при очередном подходе к 8086-архитектуре, пока опять в памяти всё не уляжется.
Для других архитектур "освежить навыки" — единицы часов или меньше.
Тут м/у языками высокого уровня когда переключаешься — и то порой некоторое время надо на перенастройку...
А там реально, каждый божий раз после некоторого перерыва раз как в новой области себя пробуешь.
Если уж начистоту, то это где-то даже унизительно.
V>>В общем, я что студентом недоумевал/возмущался, что эта кретиническая архитектура постепенно завоёвывает рынок, что сейчас уже машу рукой, но мнение не поменялось, конечно.
N>Я их кретинизм вижу совсем в другом и это не 086, это минимум 286 и дальше.
Ес-но, я говорю о развитии этого всего в 32 бита в i386-м.
Понятно же, что 16 бит были компромиссом сугубо для персоналок, когда в мейнстриме уже лет 20 было 32 бита в мейнфреймах и уже на тот момент в персональных рабочих станциях.
Как компромисс мы бы еще пережили эти вшивые 16 бит, бо им всё-равно уже маячил конец в середине 80-х...
Но они, собаки, сделали аппаратный режим виртуального 8086-го в i386-м, сделав гладкую возможность исполнять накопленное ранее бестолковейшее 16-битное ПО!
Не забудем, не простим! ))
ПО должно переноситься исключительно на уровне исходников, а не бинарников... а то развели бардак, панимашь...
Приучили к плохому...
Вон, в UNIX всё по-уму сделали еще за 10 лет до, POSIX уже закрепился независимо ни от каких операционок, а им подавай бинарную совместимость.
Идиотизм? — очередной он самый.
N>DAT без лёгкого выключения. Безумные шлюзы прерываний. Сегментация внутри виртуального пространства вместо индексации таких пространств (как сделала та же IBM). И т.д. Но уже возможность использовать любой регистр как адресный в 32-битном режиме исправила заметные проблемы.
Но кодировка инструкций доставляла — инструкции по 5-7 байт...
К лопате присобачили кофеварку, рядом садовые ножницы и вот так вырос этот франкенштейн...
Смотреть на это доставляет профессиональную боль...
Понятно же, что начни они разработку с 0-ля, без стремления к унификации с 8086, они бы сделали по-уму...
Но, но...
И эти AMD64 забили последний гвоздь в эту крышку гроба...
Теперь всё, 64 бита уж точно надолго хватит, это не "64к достаточно любой программе".
Т.е., даже в Intel прекрасно осознавали, что они натворили... хотели было исправиться...
А уже фигвам, уже созданные ими же обстоятельства были непреодолимей благородных желаний, бгг...
V>>Сейчас разрабатывать оптимизирующие компиляторы под эту архитектуру стало намного легче, конечно, ведь ADM64 узаконил доп. файл векторных регистров — теперь оптимизирующие компиляторы "почему-то" охотно используют именно их даже не в векторных операциях, бгг...
N>Ну вообще-то SSE предназначен был и для замены x87...
Стандарты SSE опицональны для реализаций x86-совместимых архитектур, AMD тут помог обязаловкой этого файла регистров хотя бы в x64-архитектуре.
ИМХО, им стоило бы сделать маленький шажок — вообще избавиться от унаследованных регистров общего назначения и тупо оставить пару файлов регистров общего назначения, поверх которых теперь есть векторные инструкции.
Я где-то понимаю, что необходимость выполнять в x64 так же 32-битные приложения продиктовали, что ле, некоторую преемственность, но тут нет никаких технических моментов, кроме психологических, ведь эти режимы неодновременны, а внутренний ремаппинг регистров делает фиолетово, как этот регистр называется на ассемблере. ))
А разработанная с 0-ля кодировка инструкций для x64 режима могла бы оботись без того Франкенштейна, который получился из изначально простой лопаты.
Сдаётся мне, что они струхнули сугубо в деле компиляторостроения, боялись, что ниасилят, бо так-то достаточно было подкрутить компилятор gcc x86 в сторону окучивания x64, поменяв совсем немного — только принцип оперирования сегментными регистрами.
N>Сейчас пишут всякие универсальные распределители. И чем бы тут ИИ помог?
В пределе это задача с огромным перебором вариантов, что неприемлимо на практике, бо скорость работы компилятора тоже важна.
ИИ мог бы где-нить в фоне "учиться" на сотнях разновидностей процов одной архитектуры, бесконечно перебирая варианты.
V>>Представь этот же код для 8086 — появятся лишние команды тусования данных по регистрам или в стек и обратно.
N>Представил. Всё равно мало таких операций.
Плохо представил. ))
V>>На PDP-11 и VAX отработали несколько моделей внешних ускорителей с плавучкой — система команд никак не влияла на представление плавучки.
V>>И именно DEC явился тем полигоном, на которых эти форматы были испробованы/отработаны и закреплены в международных стандартах.
N>IEEE был отработан на DEC? Дай ссылку.
IEEE был зафиксирован вовсе не в DEC, просто для одной и той же архитектуры DEC шли различные варианты блока вычислений с плавающей точкой с различным представлениями и правилами оперирования. Некоторые из вариантов поддерживали IEEE-784 задолго до появления этого стандарта. ))
V>>Сейчас ведь уже легко ответить на вопрос, что лучше — "отлитая из бетона" плавучка в IBM 360/370, или "оставленная на выяснение по ходу пьесы" модель PDP-11/VAX?
N>Что там могли оставить на выяснение, если для конкретной команды формат был фиксирован?
Само представление числа с плавающей точкой и правила работы с ним не были фиксированы.
Это были просто инструкции, которые генерировали определённые наборы сигналов в управляющей схеме, к которой подключался незавимиый модуль вычислений с плавающей точкой.
Это почему DEC-компьютеры можно было модернизировать в том числе повышая им производительность в плавучке, а в случае IBM 360/370 модернизация касалась только размера оперативки и периферии.
V>>Принятый в IBM 360/370 формат и соотв. правила оперирования им уступали более поздним разработкам, но!
V>>Система команд IBM 360/370 никак не опиралась на формат плавучки, т.е. этот формат мог быть доработан позже, а программы пересобраны из исходников.
N>См. выше.
На что смотреть?
Формат плавучки для IBM 360 найти легко. ))
N>И что значит "никак не опиралась" при наличии, например, ненормализующих команд?
Так а что эти команды меняют в бинарнике?
Для модульной архитектуры команда означала выдачу определённого кода на внешний сопроцессор, а для "литой" архитектуры IBM 360 — "что-то происходит с регистром".
Даже приведение к целому и обратно — этим занимается сопроцессор.
Команды — разложить на порядок и мантису или собрать обратно — аналогично.
Тут уже программист должен помнить, сколько максимально бит и там, и там у конкретного сопроцессора, чтобы не потерять данные. ))
Т.е., система команд не зависит от внутреннего представления чисел с плавающей точкой.
В 8086/8087 тоже такой прямой зависимости нет, хотя форматы жестко специфицированы.
Исключение составляют сбросы и обратное чтение файла плавающих регистров в память, где через память ты можешь подглядеть внутреннее представление плавучки.
N>То-то на современных RISC ортогональность по регистрам — почти полная, а вот подставить в любую команду константу или чтение памяти — дзуськи.
Константу легко, с памятью чуть иначе — арифметика, логика и инкремент ячеек памяти невозможны, из памяти можно только читать и писать, бо это так и происходит в проце. ))
Да и это пофик — RISC очень быстро стали суперскалярными (раньше Пентиума), обрабатывающими несколько инструкций за такт, поэтому, разложение одной операции CISC на две операции RISC ничего не ухудшили.
V>>>> усложняло компиляторы, замедляло конечный бинарник множественными пересылками м/у специализированными регистрами,
N>>>Не было там много пересылок, если заранее адекватно распределить регистры.
V>>Да не распределишь ты никак ни ручками, ни компилятором.
V>>Откомпиллируй любой сниппет под 8086 — сплошные mov м/у регистрами.
V>>Сравни с 68k.
N>И снова — боюсь, вопрос в их количестве.
Ес-но, вопрос в относительном количестве межрегистровых mov и парных push/pop.
N>Ну или покажи где это испытать можно. Какой аналог godbolt умеет 8086 и M68k?
Зачем такие сложности? ))
Бери обычный godbolt, посмотри бинарник для MIPS, ARM, Power, сравни с x86 (неважно — MSVC, clang, IC или gcc).
#include <iostream>
int main() {
int a;
std::cin >> a;
int b;
std::cin >> b;
int c;
std::cin >> c;
std::cout << ((a/b)^c*a/b);
}Для перечисленных первых архитектур код будет практически идентичным (с точностью до мнемоник и правил синтаксиса адресации регистров и памяти), а для x86-го будет куча mov и парных push/pop. ))
V>>>> зачастую аж через пары push/pop и т.д. и т.п.
N>>>Это зачем?
V>>А это уже регистров не хватает, их ведь всего 4 якобы общего назначения, а по факту они же безальтернативно дёргаются в целом ряде операций.
N>6. AX, BX, CX, DX, SI, DI. См. выше.
См. на реальный выхлоп компиляторов.
V>>И эти пары push/pop никакое переименование регистров в Pentium-Pro не оптимизирует.
N>Разве?
Конечно.
К стековой памяти может быть внешнее обращение из другого потока, о котором текущий поток может и не знать.
Процессор же не в курсе, что эти парные push/pop породил несчастный компилятор? Это ж, может, так и задумано гениальным программером!
Значит, будет честно исполнять, насилуя оперативку (когерентный кеш, отмечая его невалидность). ))
V>>Сдаётся мне, что дело было только в этом — IBM сделала ставку на невзрачную Intel, бгг...
V>>А та их потом натянула по самые ягодицы... Да и весь мир тоже.
N>Тут таки интересно, почему не сделали для неё однокристальный 360.
Сделали, но позже.
Почему 360? Скорее, 370 и эта однокристалка так и называлась.
У них поколение 370 — изначально практически полная копия 360, но в интегральном исполнении.
Виртуализация, многопроцессорность и прочее — эта разница пошла уже в индексах процов внутри 370-серии (не путать серии машин с сериями процессоров, там другие маркировки), а так-то были варианты машин, представляющие из себя практически тот же 360-й, но на новой элементной базе.
N>С доработкой пары аспектов могла бы чудесно взлететь.
Опоздали! ))
Они явно не ожидали от Intel и MS такой прыти.
Эта сладкая парочка уже зохавала мир и грабила корованы.
Уже не взлетело...
N>По скорости — только потому, что 8086 был спроектирован ужасно и даже NOP занимал 4 такта, а уж что-то сложнее в 10-20 вылезало с ходу. Зато увидев успех, решили исправить узкое место — 286 уже был сильно быстрее.
Ну, дык, я ж и говорю — СССР был вполне себе на уровне.
Т.е. на уровне ведущих мировых производителей.
Проиграл только одному игроку — Intel, ну так ему все проиграли, и на хвалённом капиталистическом Западе все проиграли тоже, бгг...
Может, не в социализме-капитализме было дело?
А в глобализации-империализме? ))
Ведь капитализм не гарантирует империализма без силого давления на другие страны.
Это надо было обеспечить распространение своей продукции без заградительных пошлин, чтобы собрать такой мировой урожай, который собирала Intel.
N>А вот по адресации памяти PDP-11 побить это не могла. DAT в режиме поклейки обоев через замочную скважину — не то, что долго работает. Даже кривоватый 20 бит тут уже лучше.
И то, и то было лишь этапом роста персоналок, поэтому смотрели сквозь пальцы.
Ведь персональные рабочие станции уже существовали и были вполне себе популярны у серьёзных дядек. ))
У MC 68к ведь 32 бита адрес!
В СССР тоже были рабочие станции на основе этого проца.
ИМХО, там было вшивое временное окно буквально в ~5 лет, которое надо было "чем-то заткнуть!", чтобы постепенно дешевеющие 32-адресные (или тру 32-битные процы) попали в персоналки своей ценой.
Но уж заткнули так заткнули...
До сих пор выткнуть сложно. ))
N>>>а вслед взамен VAX, которая была для персоналки слишком дорогая — и ни одного переходного состояния.
V>>Повторюсь, 16 бит выглядели осознанным компромиссом уже тогда, поэтому ведущие игроки планировали будущую жизнь 32 бит.
N>Вот 8086 был чудесным компромиссом с этой точки зрения.
Не так, чтобы чудесным, но да, выглядел компромиссом.
68к был бы лучше...
При том, что IBM позже "осознала косяк" и разработала архитектуру Power в содействии с Motorola, и в системе команд можно уловить много от 68k (хотя это был RISC проц, в отличие от CISC 68k).
Но поезд всё уходил и уходил, набирая обороты... ))
Да, одно время им удавалось немного бодаться...
Но теперь они бодались уже не только и не столько с Intel, сколько с Wintel. ))
По этой причине, гораздо более интересная линейка POWER-процов (серии RS/6000 и выше для серверов, PowerPC для персоналок) глотала за конкурентами пыль.
А DEC Alpha вообще был лебединой песней одного из основоположников современного IT — компании DEC.
А со стороны история Wintel напоминает абсурд из разряда — вы так много продаёте калош, а сшейте нам космический скафандр! ))
V>>В итоге мы всё-равно перешли на серверах опять к UNIX (только уже выращенном изначально на x86-й архитектуре, ес-но!)
N>Сейчас тебе куча народу тут расскажет, где они видели те сервера на UNIx
Linux — всё-равно разновидность Unix.
Изначально это только ядро, весь софт брался готовый.
GNU — операционная система типа Unix
V>>Во встраиваемой технике каждый третий проц был MIPS (хотя изначально RISC-процессор, но наследник философии VAX и 68к),
N>В чём это он их наследник? У него всё иное.
У него иное только в технологии — это RISC проц.
Просто это уже не тот RISC, которые изпервых самых, как и IBM POWER, там уже нифига не сокращённый набор команд, там просто остутствует микрокод из мира CISC.
Так микрокод и в нынешних x64 процах отсутствует (за исключением особых надобностей в утилитных режимах проца) — в "обычной" работе происходит динамическая перекодировка на подобие RISC.
N>Я бы понял, если бы ты ARM вспомнил — у него хотя бы NZVC и автоинкремент/декремент регистров. Но MIPS — смешно. Это же чистый RISC.
ARM тоже чистый RISC, причём, заметно худший изначально, бо более простой.
Но Айфоны же! ))
Вот MIPS постепенно и сдох, бо ARM получила такой буст денег, что хватило обогнать и перегнать, как грится, превратив изначально убогий RISC в более-менее вменяемый.
У них же система команд тогось, более не ARM, это уже давно совершенно новая система команд, которая со старой имеет из общего лишь часть названия. ))
V>>The Personal/370 was available as early as November 1989
N>На 10 лет позже чем нужно. Я ж говорю — надо было S/360 загнать на одну микруху.
На 8 лет.
И позже оно стало от того, что IBM стала недополучать денег от мейнфреймов из-за популярности IBM/PC и потери монополии.
Им потребовалось срочно модернизировать мейнфреймы, отсюда и появился POWER (на которых до сих пор сидит Гугл в своих датацентрах, ктстае, и не жалуется).
N>Вот именно что если добавить A0-A6 для заметной части операций — и получается 15 (я писал 14).
Не, только первые 6.
Там два регистра стека — юзерский и суперпользователя.
N>Много регистров — это много регистров.
Так-то у x86-го в сумме дофига регистров, но код всё-равно корявый из под компиляторов выходит. ))