Здравствуйте, netch80, Вы писали:


N>А вообще, разные разрядности — тоже разные системы команд, и это давно делается (любой x86 их сейчас поддерживает аж три).

Ну нет, это не так конечно. Эти разрядности — просто различные варианты одной системы команд. Оно же в корне ничего не меняется: как были вот эти переходы в зависимости от регистра флагов, так и остаются. Те же команды FPU, более крупные регистры включают в себя более мелкие.
Там же не появляются вот эти вот shadow регистры, как в Z80

Здравствуйте, playnext, Вы писали:

P>Но современное поколение в РФ в основном в армию старается не ходить. Это нормально.
Только почему то взятки теперь дают за то чтобы пойти в армию

Здравствуйте, LaptevVV, Вы писали:

LVV>Извини, но интел реально гуано после pdp-11.
Это было очень заметно до тех пор пока в системе на на х86 было 64К памяти, когда стало больше пусть даже 128К, а тем более 640, мнение уже должно было поменяться. А когда интел очень гладенько перешел на 32-модель, pdp-11 пришлось заменить другой, сходной только идейно системой, и в добавок степень "коровистости" стала уже близкой. Но Интел (AMD конечно, но без разницы) очень гладко переехал на 64бита. Можно сколько угодно извергать кирпичи, но у Интела работающая годная десктопно-серверная система

LVV>>Извини, но интел реально гуано после pdp-11.
P>Это было очень заметно до тех пор пока в системе на на х86 было 64К памяти, когда стало больше пусть даже 128К, а тем более 640, мнение уже должно было поменяться. А когда интел очень гладенько перешел на 32-модель, pdp-11 пришлось заменить другой, сходной только идейно системой, и в добавок степень "коровистости" стала уже близкой. Но Интел (AMD конечно, но без разницы) очень гладко переехал на 64бита. Можно сколько угодно извергать кирпичи, но у Интела работающая годная десктопно-серверная система
РНе...
Дело не в объеме памяти, а архитектуре системы команд.
В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.
Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.
Регистры внешних устройств адресовались адресами памяти — это блеск!
Командой пересылки осуществляется ввод-вывод!
Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие.
Одной командой можно было очистить ВСЮ память.

Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.

Здравствуйте, LaptevVV, Вы писали:

LVV>Дело не в объеме памяти, а архитектуре системы команд.
LVV>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.
Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти. Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру.

LVV>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.
LVV>Регистры внешних устройств адресовались адресами памяти — это блеск!
LVV>Командой пересылки осуществляется ввод-вывод!
Это не так уж и важно.

LVV>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие.
LVV>Одной командой можно было очистить ВСЮ память.
LVV>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.
Угу. Только интеловская плавно расширилась на 32 разряда и на 64, а для той такой возможности не было.

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>Зачем нужна своя VLIW архитектура?
Она уже есть и по большому счету ничем не хуже любой другой собственной архитектуры.

С колокольни околосистемного программиста, никогда процессоры не разрабатывавшего у VLIW есть свои плюсы, которые однако же и одновременно минусы. CISC/RISC позволяют более гибкую оптимизацию на уровне процессора, VLIW же с ее параллелизацией на уровне компилятора подразумевает что однажды скомпиленный код на будущих процессорах будет параллелиться точно так же как и на старых. То есть такая "низкоуровневость" нативного кода сильно урезает возможности новых версий процессоров более оптимально исполнять старый код. С другой стороны умные декодеры, те самые, которые в х86 позволяют параллелить код, они тоже кушать хотят, потому offload их работы на компилятор теоретически снижает энергопотребление.
Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц.

Здравствуйте, 0xCAFEDEAD, Вы писали:

W>>Она не "еще одна", а "одна из уже" существующих в промышленных масштабах.
CAF>Эльбрус существует в промышленных масштабах?
Интел с аналогичной архитектурой.

PS Как-то не предполагал, что придется разжевать, и в рот положить

Здравствуйте, playnext, Вы писали:

P>Ну а так почти в тему. Процессор военный ведь?

- На танке установлена рация...
— Товарищ майор, а рация на лампах или на транзисторах?
— Для тупых повторяю: рация на танке!

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

Здравствуйте, ononim, Вы писали:

O>Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц.

Точка зрения понятно, но есть нюанс.
Открываем https://www.archlinux32.org/packages/ смотрим на Arch.
Даже такие маргиналы как мейнтейнеры 32-х битного ArchLinux держат в репозиториях бинарники собранные под разные варианты 32-разрядного x86.

O>>Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц.
A>Точка зрения понятно, но есть нюанс.
A>Открываем https://www.archlinux32.org/packages/ смотрим на Arch.-+
A>Даже такие маргиналы как мейнтейнеры 32-х битного ArchLinux держат в репозиториях бинарники собранные под разные варианты 32-разрядного x86.
Ну я ж писал что в опенсурсе тоже норм. В целом более тесная связка компонентов системы подразумевает большие возможности для оптимизации и меньшие — для унификации. В данном случае компоненты — проц и компилятор.

Здравствуйте, ononim, Вы писали:

O>>>Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц.
A>>Точка зрения понятно, но есть нюанс.
A>>Открываем https://www.archlinux32.org/packages/ смотрим на Arch.-+
A>>Даже такие маргиналы как мейнтейнеры 32-х битного ArchLinux держат в репозиториях бинарники собранные под разные варианты 32-разрядного x86.
O>Ну я ж писал что в опенсурсе тоже норм. В целом более тесная связка компонентов системы подразумевает большие возможности для оптимизации и меньшие — для унификации. В данном случае компоненты — проц и компилятор.

А много ли народу в современных линуксах что-то там пересобирают на своих компах?
Поголовно качают уже готовые бинарники с репозиториев. Даже когда пользователями являются профессиональные специалисты из мира разработки софта. Сколько реально осталось source based дистрибутивов линукса и какое количество пользователей у них?

Будет в репозиториях лежать несколько вариантов бинарников — под разные варианты поколения VLIW, так же как делали последние года с вариациями 32-разрядного x86.

В тоже время, у Эльбрусов давно есть встроенный бинарный транслятор x86-инструкций в VLIW-машкод. А это гораздо сложнее, чем сконвертировать VLIW-инструкции одного поколения под более новое. Так что вопрос унификации под разные VLIW может решаться и бинарной трансляцией — как динамической, так и с кэшированием. Например, как в случае приложений под современные Android'ы, то самое «выполняется оптимизация приложений».

Здравствуйте, LaptevVV, Вы писали:

Как человек, никогда не видевший PDP-11, могу ли я поинтересоваться?

LVV>Дело не в объеме памяти, а архитектуре системы команд.

Ее в самом деле сильно хвалили, но в чем там фишка, не рассказывали.

LVV>В pdp все было единообразно,

В чем заключалось единообразие, можешь просветить?

LVV>аргументы могли располагаться где угодно.

Это как? Разве не через стек шла передача аргументов? Это на ЕС не было стека, приходилось выделять память, оставлять адрес выделенной области в одном из регистров, потом на входе все очищать. Поэтому на ЕС рекомендовали не злоупотреблять вызовами подпрограмм.

LVV>Методы адресации — единообразные.

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

LVV>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.

То есть, выполнялся одной командой?

LVV>Регистры внешних устройств адресовались адресами памяти — это блеск!
LVV>Командой пересылки осуществляется ввод-вывод!

Такое было на Motorola 68040. Часть памяти отображалась на ввод/вывод. Не нужна была отдельная команда чтения/записи в порт. Но какие преимущества это давало при программировании, я не очень понимаю.

Пока все, пожалуй. Может, еще что потом вспомню.

P.S. на третьем курсе один из наших преподов любил повторять: глупых вопросов не бывает.

Здравствуйте, pagid, Вы писали:

LVV>>Дело не в объеме памяти, а архитектуре системы команд.
LVV>>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.
P>Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти.

Это не имеет никакого отношения к архитектуре системы команд.
VAX и M68k имели по сути такую же архитектуру — вершина CISC, любой аргумент почти любого типа. Но у них уже было 32-битное пространство без сложностей по рассматриванию огромного мира в крошечное окошко.

P> Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру.

Не переезжало оно без напрягов: в 32 битах его тупо не используют — безумных нет, а в 64 и нельзя использовать напрямую.

Вот если бы они сделали в стиле IBM, что в 32 и 64 битах сегментные регистры выбирают корневой страничный каталог — их бы использовали и по делу.

LVV>>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие.
LVV>>Одной командой можно было очистить ВСЮ память.
LVV>>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.
P>Угу. Только интеловская плавно расширилась на 32 разряда и на 64, а для той такой возможности не было.

Ничего такого "плавного" в x86 не было. Парсинг команд в 32 и 64 заметно другой и разный между ними самими. Дополнительные регистры добавлены костылями, как и 64-битные данные большинства команд. Методы адресации заметно перестроились.
Видимость сходства, да, но внутри совсем другое.
Лучше бы, сохраняя общую архитектуру, полностью перекроили построение системы команд с нуля.
Но AMD были нищие и не могли это себе позволить.

Здравствуйте, Privalov, Вы писали:

P>Ее в самом деле сильно хвалили, но в чем там фишка, не рассказывали.
Там очень простая, но универсальная система команд. Восемь регистров, практически равноценных, за исключением, того, предпоследний это указатель стека, а последний указатель команд. Все методы адресации применимы практически ко всем командам и операндам.

P>Это как? Разве не через стек шла передача аргументов?
Видимо не аргументы, а операнды

LVV>>Методы адресации — единообразные.
P>И этого не понял. Во все времена адресация была прямая, непосредственная, несколько типов косвенной. Я что-то пропустил?
С автоинкрементом и автодекрементом
Вот это
*(p++) = *(s++)
компилируется в одну машинную команду

Здравствуйте, LaptevVV, Вы писали:

LVV>РНе...
LVV>Дело не в объеме памяти, а архитектуре системы команд.
LVV>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.

Неправда. На единообразие им тупо не хватило места в 16 битах.
ADDB, SUBB байтные — не введены.
XOR, MUL, DIV, ASH, ASHC имеют одним аргументом только регистр.
Для обычной группы сдвигов (ASL, ASR, ROL, ROR) не хватило места на аргумент — величину сдвига.
Про плавучку вообще молчу — группа FIS брала аргументы со стека и возвращала результат на стек, потому что иначе не нашли места для аргументов.

LVV>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.

Причём косвенные их варианты использовались чуть чаще, чем никогда (режим 3 по PC не в счёт).

LVV>Регистры внешних устройств адресовались адресами памяти — это блеск!

Да, это впервые появилось именно в PDP-11. Позднее из неё распространилось на всех. Так же как схема флагов NZVC.

LVV>Командой пересылки осуществляется ввод-вывод!

А вот то, что MOV ставила флаги, признано ошибкой и с 80-х никем не повторяется.

LVV>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие.
LVV>Одной командой можно было очистить ВСЮ память.

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

LVV>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.

Зато идейный последователь подхода PDP-11 в лице M68k — умер в начале 90-х, потому что не смог перейти со своей универсальностью в мир, где out-of-order исполнение, переименование регистров и иерархия кэшей.

Здравствуйте, jamesq, Вы писали:

N>>А вообще, разные разрядности — тоже разные системы команд, и это давно делается (любой x86 их сейчас поддерживает аж три).

J>Ну нет, это не так конечно. Эти разрядности — просто различные варианты одной системы команд. Оно же в корне ничего не меняется:

У них разные, несовместимые парсеры.
В отличие, например, от IBM zSeries, у которой добавлены 64-битные команды, не ломая старые, а разрядность адреса (24/31/64) свободно управляется непривилегированной командой.
При совершенно разных системах команд сделать совместимость по общей части пула регистров — банально, это делали и PDP-11+VAX, и ARM/32+ARM/64, и x86-32+IA64, и x86 со всеми тремя режимами. Но это не создаёт всем одинаковую систему команд.

J> как были вот эти переходы в зависимости от регистра флагов, так и остаются. Те же команды FPU,

Которое фактически deprecated и Intel регулярно грозится исключить его совсем, или перевести на микрокод, с замедлением на порядок.

J> более крупные регистры включают в себя более мелкие.
J>Там же не появляются вот эти вот shadow регистры, как в Z80

Эээ... не знаю, почему для вас shadow регистры это признак другой системы команд, а не системного расширения текущей, но на всякий случай напомню, что в x86 пул FP регистров = пулу MM, но не пулу XMM/YMM/ZMM, последний — совсем другие регистры.

Здравствуйте, Privalov, Вы писали:

P>Как человек, никогда не видевший PDP-11, могу ли я поинтересоваться?

LVV>>Дело не в объеме памяти, а архитектуре системы команд.
P>Ее в самом деле сильно хвалили, но в чем там фишка, не рассказывали.

Для некоторого основного набора команд (MOV, ADD, SUB, BIS, CMP...) источник и приёмник могли быть абсолютно любого типа из поддерживаемых, и независимо друг от друга. Память, регистры — не важно.
Плюс к тому:
1) Работа со стеком без отдельных приёмов — работал автоинкремент и автодекремент.
2) Эти самые автоинкремент и автодекремент работали для любого регистра, сокращая операции на последовательную работу с областью памяти.
3) Сюда же универсально легли методы задать любой команде константу-литерал или абсолютный адрес в памяти через использование регистра PC для адресации; тут же была адресация относительно PC (которую в x86 сделали только в 64 битах, раньше не было) — для позиционно-независимого кода.

LVV>>аргументы могли располагаться где угодно.
P>Это как? Разве не через стек шла передача аргументов?

Можно было и через регистры, и через стек.
Но на PDP-11 был ещё один интересный фокус: аргументы подпрограммы посреди вызывающего кода, сразу за командой JSR — вызова подпрограммы. Использовался для этого регистр связи, отличающийся от PC.

P> Это на ЕС не было стека, приходилось выделять память, оставлять адрес выделенной области в одном из регистров, потом на входе все очищать. Поэтому на ЕС рекомендовали не злоупотреблять вызовами подпрограмм.

Сейчас там точно так же нет стека, но GCC компилирует в ABI, в котором стек сделан на R13. И используют — почти как на x86: декрементировал на входе в подпрограмму, попользовался в локальных смещениях (доступны и отрицательные, но команда на 2 байта длиннее), инкрементировал обратно на выходе.

LVV>>Методы адресации — единообразные.
P>И этого не понял. Во все времена адресация была прямая, непосредственная, несколько типов косвенной. Я что-то пропустил?

См. выше. Например, непосредственная константа в команде — через (PC)+, абсолютная адресация — через @(PC)+.

Например, команда "записать 41 по адресу 25" (считаем, оба восьмеричные):

MOV #41, @#25

на самом деле она превращалась в последовательность:

MOV (PC)+, @(PC)+
.WORD 41
.WORD 25

В x86 и аналогах для непосредственной константы надо делать отдельный тип команды.

Что интересно, можно было делать и следующую хохму:

MOV R0, (PC)+
X: .WORD 0

записал себе в ячейку прямо в коде и пошёл дальше потом из этой X прочитать (в относительной адресации).

LVV>>Регистры внешних устройств адресовались адресами памяти — это блеск!
LVV>>Командой пересылки осуществляется ввод-вывод!
P>Такое было на Motorola 68040. Часть памяти отображалась на ввод/вывод. Не нужна была отдельная команда чтения/записи в порт. Но какие преимущества это давало при программировании, я не очень понимаю.

Так на x86 тоже такого сейчас до чёрта, и даже рекомендуют укладывать большие области регистров на память.
Из стандартных устройств только на память отображаются все APIC, HPET...
И на MIPS, ARM, многих других нет отдельного I/O, только через пространство памяти.
X86 старый в этом смысле — уникум.

CAF>>>А что потом то? И зачем оборонке своя архитектуры. Ну вот сделали Байкал — понимаю, свой завод — понмаю. Все железо — да. Но Эльбрус то зачем?

Gt_>>что бы не грустить потом как хуавей, с его байкалом. упаковать арм ядра может и хуавей, но нужен то всем полноценный проц, а не еще один байкал.

CAF>Зачем нужна своя VLIW архитектура?

что бы не упереться в производительность одного потока как интел с x86. vliw позволяет больше инструкций за такт + перенести блок предсказаний в компилятор.
пытаться с двумя деревянными рублями догнать интел просто глупо, посоревноваться с интелом и арм сможет лишь то, что будет в разы больше инструкций за такт прожевывать. например vliw.

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.

Вот именно такой подход ("А когда мы отобъем своё бабло и с каким наваром?") в сфере национальной безопасности приводит
к ситуации, которая сейчас наблюдается, например в США в области производства обогащенного урана.
Американская обогатительная корпорация была в своё время приватизирована (неужели наши приватизаторы надоумили? ) именно с целью
максимизации прибыли от отрасли. В итоге оказалось, что выгоднее перепродавать российский уран, чем добывать и обогащать свой.
В итоге имеются признаки развала урановой отрасти (капитилистического народного хозяйства ).
Я полагаю, не надо повторять, что свои микропроцессоры — это тоже сфера национальной безопасности.