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

AK>>Спектрум-совместимые в промышленных масштабах по приемлемой цене появились ещё с середины 80-х.
E>С середины 80-х в достаточных масштабах они в буржундии только появились.

К 1986-1987гг Спектрумы в России уже были. Причём, почти что "в свободной продаже" и по доступной цене.
В магазинах не было, но кому надо — через знакомых доставали.

E>Спектрум клоны же начали появляться не в середине, а в конце 80-х.

Ну пусть будет "в конце 80-х".

E>"Ленинград" — это 1989 год. А то и 91-й, в зависимости от модификации. "Львов" в теории можно было купить и раньше.

Мой "Спектрум" приехал из Ленинграда — к отцу в гости сокурсник приехал и привёз по заказу. Отец сказал тогда, что оно "ленинградской сборки", но что именно это значило — я не знаю. Может, кустарное производство. Это было лето 1988-го. Процессор там стоял "родной", Z80 (возможно, клон, но маркировка была именно Z80), а вот микросхемы памяти и всё остальное — советское.
Другие детали посмотреть уже негде, я от него давно избавился за ненадобностью.

E>Вот только факт заключается в том, что до 91-года компов у населения было очень и очень мало. И массово у населения они начали появляться в первой половине 90-х годов, тогда они были у весьма многих.

Я и в 90-х годах мало у кого видел Спектрумы. Из всех моих друзей детства, счастливыми обладателями Спектрумов были некоторые однокурсники отца и четверо моих друзей. Двое из моих друзей купили спектрумы как раз в начале 90-х, все остальные — в 87-88гг.

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

OE>Однако, как точно автор обрисовал лицо развитого социализьма — желание "ободрать идеи у всех остальных" осталось, а вот Берии-то, чтоб это воплотить в жизнь уже нету. Ай-ай-ай, какая жалость.
Это характерно не только для развитого социализма.
У Перельмана китайские товарищи пытались отъять его результаты.
Вот этот товарисч: http://www.dissercat.com/content/vychislitelnye-metody-fiziki-vysokikh-energii
который входит в 1000 самых цитируемых ученых России, мне писал, что немцы дерут все подчистую (в его области), совершенно не стесняясь.

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

E>>Какой i8086 у БК? Погугли хотя бы, если не застал то время. Всю жизнь было это PDP-11. Или К1801ВМ1
BZ>это клон микропроцессора LSI-11
Это Электроника-60 с комплектом К581 клон LSI-11, а К1801ВМ1 это просто микропроцессор с архитектурой PDP-11

BZ>ЕС-1840 стоила тысячи рублей так что на домашний комп никак не тянула
Да, это совсем не домашний комьютер.

N>>>>>Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
E>>>>Например, такую команду ?
N>>>Я же сказал — and, or. Также eor, bic. Вообще-то и арифметика тоже годится. Константа формируется из базового значения и сдвига для образования финальной константы.
E>>Приведи пожалуста конкретный пример в ассемблерном коде, что бы разговор был более предметным.
N>eor %r1, #0x100000
N>скормите ассемблеру и посмотрите, что он сгенерирует. Должно получиться внутри что-то вроде "eor %r1, #1, ror#12", хотя он может выбрать другую базовую константу и соответственно другой сдвиг.

01 36 83 E3                 ORR     R3, R3, #0x100000

Еще раз повторю — это одна единственная машинная команда.
PS: И пример выбран совершенно неудачно.

N>>>>>А вообще очень прошу объяснить, почему это вдруг такие команды стали "мрачными отголосками CISC".
N>>>>>Накойхер (tm) требовать переводить в цепочку "загрузить 1 — сдвинуть — выполнить операцию" то, что элементарно выполняется в пределах одной команды чуть более продвинутым железом?
E>>>>Так никто не делает.
N>>>Такие утверждения требуют доказательства. Особенно когда видно противоположное.
E>>Для начала, будь добр, приведи доказательство предыдущего своего утверждения.
N>Я уже привёл трижды. Вы не знаете устройство ARM или не хотите читать?
Я не видел.

N>>>Метко подмечено. Ну а если попробовать всё-таки распарсить моё предложение?
E>>Ваше предложение распарсено. Оно не соотвесвует истине, ибо противоречит фактам. Точка.
N>Вы таки пытаетесь что-то рассказывать об области, в которой абсолютно невежественны и столь же абсолютно упорны.
Лично я говорю об области которой посвятил не один год и не два.

N>>скормите ассемблеру и посмотрите, что он сгенерирует. Должно получиться внутри что-то вроде "eor %r1, #1, ror#12", хотя он может выбрать другую базовую константу и соответственно другой сдвиг.
E>

E>01 36 83 E3                 ORR     R3, R3, #0x100000
E>

E>Еще раз повторю — это одна единственная машинная команда.
E>PS: И пример выбран совершенно неудачно.
А неудачно он выбран потому что на твоих любимых CISC-ах этот код будет гораааздо длиньше:

81 C9 00 00 10 00                             or      ecx, 100000h

или самый что нинаесть CISC-овый путь:

B8 01 00 00 00                                mov     eax, 1
C1 E0 14                                      shl     eax, 14h
0B C8                                         or      ecx, eax

E>>>>Гипотетическое неограниченое развитие системы команд никому не нужно.
N>>>Боюсь, Intel с этим не согласен. Почти каждый год они добавляют что-то новенькое, сохраняя старое со всеми его спецификами. Вон даже в 64-битном коде отдельный байт верхнего уровня на какое-то нелепое "mov al,imm8", а рядом новые суперкоманды.
E>>Ваши "боюсь" мне совсем не интересны.
N>Когда начинаются такие отговорки, это обычно признак того, что аргументы заканчиваются.
Это констатация факта.

E>> Intel делает то что хочет — это его право.
N>Кто бы спорил, я не буду. Но ведь это как раз показатель того, что "гипотетическое неограниченное развитие системы команд" не "никому не нужно"? Как минимум один, кому это нужно, уже показан. Сюда же автоматически можно включить AMD. Вы принципиально исключаете из рассмотрения двух игроков этой отрасли, в сумме имеющих >95% рынка десктопов и серверов? Если да, то в чём заключается этот Ваш принцип?
Принцип очень прост — в современных реалиях обратная совместимость на уровне машинных команд со старыми процессорами не нужна.

E>>>>В расширениях ARM есть векторные инструкции и уже довольно давно (еще со времен StrongARMа — это 2003 год примерно).
N>>>Я просил аналог именно AVX2 (ну ладно, можно и просто AVX), а не вообще "векторные инструкции", реализуемые, BTW, как обращение к сопроцессору (что резко смягчает требования к умещению в прокрустово ложе стандартного конвейера). И как они влезут в существующее пространство команд? Заведёте ещё один номер сопроцессора?
А зачем им влезать в существущее пространство команд ? И зачем заводить какой-то мифический еще один номер сопроцессора ?

E>>Вам и привели технологию по смыслу аналогичную AVX2.
N>Если она аналогична, тогда для Вашего рассмотрения MMX и SSE — это одно и то же, а какой-нибудь FMA вообще левая незначительная деталь.
E>> Векторная арифметика логически реализуется одельным сопроцессором, в ARM их может быть до 16 штук. Физически это может быть тот же самый кристал с тем же 0.5 такта на команду.
N>Вы цитируете основы документации вместо конструктивного ответа. Повторю вопрос. Когда кончатся коды команд, Вы аллоцируете новый номер сопроцессора?
Что вы подразумеваете под аллоцированием номера сопроцессора ? Все сопроцессоры равноправны, их набор и функции определяется конкретной реализацией системы.

N>>>>>Reduced в RISC не потому, что команд мало или они короткие, а потому, что они простые. Никаких сложностей стиля mov ofs(%7), @(%2)+ в PDP-11. Всё исполнение должно уложиться на стандартные 5 тактов (в среднем по архитектурам). При этом ничто не мешает создать 100500 команд под каждый тонкий частный случай.
E>>>>Как правило, команд мало. Конкретно для ARM — 1 команда (любая) занимает 0.5 такта.
N>>>Полтакта на команду — Вы эту демагогию оставьте младшей группе ясель, а мы вроде тут взрослые люди. Речь не про суммарный throughput в пересчёте на команду, а про длительность отработки каждой команды от посылки запроса на чтение из памяти до финальной фиксации результатов.
E>>Это не демагогия, а факт. Понятно, что когда нечем аргументировать некоторые личности вспоминают про "младшую групу ясель".
N>"Нечем аргументировать" это про Вас.
Про ясли начали вы. Так что про вас.

E>> Сумарное время зависит от конкретного железа, наличия и отсутсвия кешей и много другого, точно также как и дляч платформы x86.
N>Что такое "суммарное время" в Вашем понимании? Вот в руководстве по оптимизации для x86 для каждой команды чётко выписаны значения latency и throughput, хотя бы в диапазонах значений, для идеального случая (все данные в ближайших кэшах), указаны условия увеличения этих значений, влияние задерживающих факторов. Поведение инструкции такого процессора в принципе не может быть описано одним числом. Вы же явно загрубляете описание в том случае, когда детали принципиально важны, и уходите от ответа.
Еще повторю — время выполнения 1 инструкции _внутри_ процессора — 0.5 такта. Суммарное время — зависит от архитектуры системы, интерфейса к памяти, наличия различных внешних кешей. Что здесь вам неясно ?

N>>>И про мало команд — не надо смешить. Фактически с точки зрения CISC каждая из ARM'овских вариаций — условие выполнения, менять/нет CC, значение сдвига для op2 есть или нет — создаёт новую ось пространства команд. В результате там, где в CISC, грубо говоря, 100 команд, в RISC типа ARM их получается несколько тысяч.
E>>Вы говорите абсолютную чушь. Армовская команда — одна и в ней указывается то что нужно сделать, как, и в каком случае.
N>Именно! Каждая отдельная команда — одна. Но всего таких команд может быть, если подсчитать по методам, как считают команды для CISC, тысячи.
Все команды приведены в описании процессоров. Общее их кол-во гораздо меньше CISC набора. Всё.
Ваши наколенные методики подсчета меня не интересуют ибо это демагогия.

N>Вы вообще читаете, на что отвечаете, или решили просто отмахнуться, увидев знакомые слова?
Еще раз — ваши хитрожопые наколенные методики подсчета никому не интересны.

E>> При CISC подходе для этого требуется 100500 различных команд — различные проверки статусных битов, команды условного перехода и многое другое.
N>Это не "CISC подход", учитывая, что условное выполнение команд по методу ARM32 убрали даже в его ближайшем родственнике AArch64, и его не было в Thumb. Фактически, мало в каком RISC это было. Вы и тут не разбираетесь в теме, однако.
Убрали, не было — и что ? В ARM условное выполнение есть, это факт. Это условное выполнение удобно, это тоже факт. Вы тут не разбираетесь в теме, всё.

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

[skip много лишнего]

E>Принцип очень прост — в современных реалиях обратная совместимость на уровне машинных команд со старыми процессорами не нужна.

Скажите это авторам софта под Windows. Которого до сих пор до хрена и больше ещё с ранних 32-битных времён.

E>А зачем им влезать в существущее пространство команд ? И зачем заводить какой-то мифический еще один номер сопроцессора ?

"Если сообщения не доходят — прочитайте их ещё раз"

E>Про ясли начали вы. Так что про вас.

Вы уже придумали, какая именно разновидность святого духа помогает выполнять одну команду за полтакта (а не 100 команд за 50 тактов)? Требуется ли для этого, например, икона Георгия-победоносца?

E>Еще повторю — время выполнения 1 инструкции _внутри_ процессора — 0.5 такта.

Дададад. И за это время её успели прочитать, раскодировать, найти аргументы, применить сдвиги, вызвать АЛУ...
Я вынужден повторить про младшую группу ясель. В старшей хотя бы некоторые знают основы цифровой схемотехники, для этого на детских площадках есть качели.

E>Убрали, не было — и что ? В ARM условное выполнение есть, это факт. Это условное выполнение удобно, это тоже факт. Вы тут не разбираетесь в теме, всё.

Уж кто бы говорил

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

N>>скормите ассемблеру и посмотрите, что он сгенерирует. Должно получиться внутри что-то вроде "eor %r1, #1, ror#12", хотя он может выбрать другую базовую константу и соответственно другой сдвиг.
E>

E>01 36 83 E3                 ORR     R3, R3, #0x100000
E>

E>Еще раз повторю — это одна единственная машинная команда.

Именно! Это то, что я доказывал.

E>PS: И пример выбран совершенно неудачно.

То, что я хотел, я им проиллюстрировал.

N>>Вы таки пытаетесь что-то рассказывать об области, в которой абсолютно невежественны и столь же абсолютно упорны.
E>Лично я говорю об области которой посвятил не один год и не два.

И, судя по соседнему письму с фантастикой про выполнение одной команды за полтакта, вы там ничего не поняли.
Ну или так пишете письма.
Жаль (в обоих случаях).

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

N>>>скормите ассемблеру и посмотрите, что он сгенерирует. Должно получиться внутри что-то вроде "eor %r1, #1, ror#12", хотя он может выбрать другую базовую константу и соответственно другой сдвиг.
E>>

E>>01 36 83 E3                 ORR     R3, R3, #0x100000
E>>

E>>Еще раз повторю — это одна единственная машинная команда.
E>>PS: И пример выбран совершенно неудачно.
E>А неудачно он выбран потому что на твоих любимых CISC-ах этот код будет гораааздо длиньше:
E>

E>81 C9 00 00 10 00                             or      ecx, 100000h
E>

Я вообще-то изначально намекал на следующее:

$ echo 'bts $20,%ecx' | as -al -o /dev/null
GAS LISTING                     page 1


   1 0000 0FBAE914      bts $20,%ecx

Получилось 4 байта. Ну да, слишком много разной ерунды на префиксы уходит. Но уже не длиннее. И это одна аккуратная команда. А если ей задать не только регистр, то получится и короче ARM'овского эквивалента:

$ echo 'bts $20,-4(%esp)' | as -al -o /dev/null
GAS LISTING                     page 1


   1 0000 0FBA6C24      bts $20,-4(%esp)
   1      FC14

6 байт вместо минимум 12 на 3 команды (прочитать в регистр, поставить бит, записать в память).

E>или самый что нинаесть CISC-овый путь:
E>

E>B8 01 00 00 00                                mov     eax, 1
E>C1 E0 14                                      shl     eax, 14h
E>0B C8                                         or      ecx, eax
E>

Вы не разбираетесь в CISC. Это же надо — на i386 делать такие вещи через mov+shl...

E>>Принцип очень прост — в современных реалиях обратная совместимость на уровне машинных команд со старыми процессорами не нужна.
N>Скажите это авторам софта под Windows. Которого до сих пор до хрена и больше ещё с ранних 32-битных времён.
А им еще кто-то пользуется ? Софт под виндовс в основном слишком монструозен и убог по функциональности.

E>>А зачем им влезать в существущее пространство команд ? И зачем заводить какой-то мифический еще один номер сопроцессора ?
N>"Если сообщения не доходят — прочитайте их ещё раз"
Пожалуй проскипаю.

E>>Про ясли начали вы. Так что про вас.
N>Вы уже придумали, какая именно разновидность святого духа помогает выполнять одну команду за полтакта (а не 100 команд за 50 тактов)? Требуется ли для этого, например, икона Георгия-победоносца?
Хм, интересный переход в религиозные темы. Но я ориентируюсь на спецификации от производителей.

E>>Еще повторю — время выполнения 1 инструкции _внутри_ процессора — 0.5 такта.
N>Дададад. И за это время её успели прочитать, раскодировать, найти аргументы, применить сдвиги, вызвать АЛУ...
Именно так и мне, как пользователю, совершенно не важна внутреняя кухня раскодирования, аргументов сдвигов и прочего — это внутреняя иепархия вендора. И это есть огромный плюс.

N>Я вынужден повторить про младшую группу ясель. В старшей хотя бы некоторые знают основы цифровой схемотехники, для этого на детских площадках есть качели.
Опять демагогия включилась. Вам надо лечится.

E>>Убрали, не было — и что ? В ARM условное выполнение есть, это факт. Это условное выполнение удобно, это тоже факт. Вы тут не разбираетесь в теме, всё.
N>Уж кто бы говорил
Я Вам и говорю.

N>Я вообще-то изначально намекал на следующее:
N>$ echo 'bts $20,%ecx' | as -al -o /dev/null
N>GAS LISTING page 1
N> 1 0000 0FBAE914 bts $20,%ecx

N>Получилось 4 байта. Ну да, слишком много разной ерунды на префиксы уходит. Но уже не длиннее. И это одна аккуратная команда. А если ей задать не только регистр, то получится и короче ARM'овского эквивалента:
N>$ echo 'bts $20,-4(%esp)' | as -al -o /dev/null
N>GAS LISTING page 1
N> 1 0000 0FBA6C24 bts $20,-4(%esp)
N> 1 FC14

N>6 байт вместо минимум 12 на 3 команды (прочитать в регистр, поставить бит, записать в память).
Но эти команды на самом деле не нужны — достаточно обычной двоичной логики.


E>>или самый что нинаесть CISC-овый путь:
E>>B8 01 00 00 00 mov eax, 1
E>>C1 E0 14 shl eax, 14h
E>>0B C8 or ecx, eax

N>Вы не разбираетесь в CISC. Это же надо — на i386 делать такие вещи через mov+shl...
Как раз самая коренная идеология CISC. Понятно что на i386 можно сделать короче и по другому, это приведено как иллюстрация.

N>Именно! Это то, что я доказывал.
Где вы это доказывали, кому и зачем ?

E>>PS: И пример выбран совершенно неудачно.
N>То, что я хотел, я им проиллюстрировал.
Почему этот пример неудачен я уже написал.

N>>>Вы таки пытаетесь что-то рассказывать об области, в которой абсолютно невежественны и столь же абсолютно упорны.
E>>Лично я говорю об области которой посвятил не один год и не два.
N>И, судя по соседнему письму с фантастикой про выполнение одной команды за полтакта, вы там ничего не поняли.
Мне и не надо ничего понимать, додумывать или обращаться к религии — я использую железо так, как написано в соответсвующей документации.

N>Ну или так пишете письма.
N>Жаль (в обоих случаях).
Ваш поток сознания не распарсен.

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

E>>Ну и как с размером программ на БК-0010? Тот же z80 это все рвет как тузик грелку, несмотря на 8 битность.
E>БК-0010 была основана на К1810ВМ86/К1810ВМ88 — это аналоги i8086/i8088, натуральный CISC. Ты о чем спросить то хотел ?

У БК-0010 имела систему комманд PDP-11.

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

N>>6 байт вместо минимум 12 на 3 команды (прочитать в регистр, поставить бит, записать в память).
E>Но эти команды на самом деле не нужны — достаточно обычной двоичной логики.

Расшифруйте.

E>>>или самый что нинаесть CISC-овый путь:
E>>>B8 01 00 00 00 mov eax, 1
E>>>C1 E0 14 shl eax, 14h
E>>>0B C8 or ecx, eax
N>>Вы не разбираетесь в CISC. Это же надо — на i386 делать такие вещи через mov+shl...
E>Как раз самая коренная идеология CISC.

Это где-то документировано? Что надо, например, тратить загрузку 4-байтной константы 1 и затем её сдвигать, вместо (хотя бы) загрузки уже сдвинутого того же размера — это "коренная идеология CISC"?? Пока что я вижу только Вашу буйную фантазию, что это есть "коренная идеология CISC", и никаких подтверждений. Начиная ещё с S/360 для таких вещей старались брать готовые константы.

E> Понятно что на i386 можно сделать короче и по другому, это приведено как иллюстрация.

Иллюстрация чего? Где и на каком CISC Вы видели такие подходы как основные?
Я работал из CISC'ов и близких к ним — с S/360 (в виде ЕС 10xx), PDP-11, 6502, 8080, x86. (Вот VAX'а не довелось пощупать, увы. И M68k не попался.) Нигде такого не рекомендовалось и не считалось единственным вариантом.
Или Вы просто увидели код после какого-нибудь SmallC, который не умел оптимизировать в compile time даже вычисления констант, и делаете на этом основании выводы? Тогда Вам надо срочно освежать впечатления — как минимум на 20 последних лет.

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

E>>>Принцип очень прост — в современных реалиях обратная совместимость на уровне машинных команд со старыми процессорами не нужна.
N>>Скажите это авторам софта под Windows. Которого до сих пор до хрена и больше ещё с ранних 32-битных времён.
E>А им еще кто-то пользуется ?

Знаете ли, да. Если не надевать на глаза шоры, которые не позволяют увидеть ничего кроме планшетов — то можно видеть много интересного. В том числе и корпоративный мир с его спецификой, и множество специфических отраслей, где сидят на разработках 50-летней давности и очень неохотно освежают их...

E> Софт под виндовс в основном слишком монструозен и убог по функциональности.

Это Вы по солитеру судите?

E>>>Про ясли начали вы. Так что про вас.
N>>Вы уже придумали, какая именно разновидность святого духа помогает выполнять одну команду за полтакта (а не 100 команд за 50 тактов)? Требуется ли для этого, например, икона Георгия-победоносца?
E>Хм, интересный переход в религиозные темы. Но я ориентируюсь на спецификации от производителей.

Ну тогда Вам осталось сделать небольшой последний шаг — начать понимать, что же именно в них написано.

E>>>Убрали, не было — и что ? В ARM условное выполнение есть, это факт. Это условное выполнение удобно, это тоже факт. Вы тут не разбираетесь в теме, всё.
N>>Уж кто бы говорил
E>Я Вам и говорю.

А надо бы — своему отражению. Кстати, с кем это Вы спорили, что в ARM есть (точнее, было — в AArch64 его отменили) условное выполнение? я его как-то не отрицал.

E>>>>Принцип очень прост — в современных реалиях обратная совместимость на уровне машинных команд со старыми процессорами не нужна.
N>>>Скажите это авторам софта под Windows. Которого до сих пор до хрена и больше ещё с ранних 32-битных времён.
E>>А им еще кто-то пользуется ?
N>Знаете ли, да. Если не надевать на глаза шоры, которые не позволяют увидеть ничего кроме планшетов — то можно видеть много интересного. В том числе и корпоративный мир с его спецификой, и множество специфических отраслей, где сидят на разработках 50-летней давности и очень неохотно освежают их...
Корпоративный мир давно уже отходит в сторону от windows, хотя ваше нии врядли относится к корпоративному миру.

E>> Софт под виндовс в основном слишком монструозен и убог по функциональности.
N>Это Вы по солитеру судите?
Назовите хотя бы один продукт под windows для которого это неверно.

E>>>>Про ясли начали вы. Так что про вас.
N>>>Вы уже придумали, какая именно разновидность святого духа помогает выполнять одну команду за полтакта (а не 100 команд за 50 тактов)? Требуется ли для этого, например, икона Георгия-победоносца?
E>>Хм, интересный переход в религиозные темы. Но я ориентируюсь на спецификации от производителей.
N>Ну тогда Вам осталось сделать небольшой последний шаг — начать понимать, что же именно в них написано.
Но вам для этого надо начать хотя бы с языка.

E>>>>Убрали, не было — и что ? В ARM условное выполнение есть, это факт. Это условное выполнение удобно, это тоже факт. Вы тут не разбираетесь в теме, всё.
N>>>Уж кто бы говорил
E>>Я Вам и говорю.
N>А надо бы — своему отражению.
Если вы считаете себя моим отражением то вы — больной человек. Я Вам соболезную.

N>Кстати, с кем это Вы спорили, что в ARM есть (точнее, было — в AArch64 его отменили) условное выполнение? я его как-то не отрицал.
Вас, на всякий случай, в известность я поставил. Мало ли.

Pzz>У БК-0010 имела систему комманд PDP-11.
Скажи мне — у вас там массовый зомби паралич ? Вы вообще читать вообще умеете ?
Выше я написал, что перепутал. Тонкое различее между сериями K1810 и K1801.

N>>>6 байт вместо минимум 12 на 3 команды (прочитать в регистр, поставить бит, записать в память).
E>>Но эти команды на самом деле не нужны — достаточно обычной двоичной логики.
N>Расшифруйте.
Расшифровываю — читать дословно и понимать буквально.

N>Это где-то документировано? Что надо, например, тратить загрузку 4-байтной константы 1 и затем её сдвигать, вместо (хотя бы) загрузки уже сдвинутого того же размера — это "коренная идеология CISC"?? Пока что я вижу только Вашу буйную фантазию, что это есть "коренная идеология CISC", и никаких подтверждений. Начиная ещё с S/360 для таких вещей старались брать готовые константы.
Коренная идеология CISC — "на каждый чих своя команда", остальное иллюстрация. И не надо поясничать на примере.

E>> Понятно что на i386 можно сделать короче и по другому, это приведено как иллюстрация.
N>Иллюстрация чего? Где и на каком CISC Вы видели такие подходы как основные?
См. выше. CISC по своему определению состоит из таких команд.

N>Я работал из CISC'ов и близких к ним — с S/360 (в виде ЕС 10xx), PDP-11, 6502, 8080, x86. (Вот VAX'а не довелось пощупать, увы. И M68k не попался.) Нигде такого не рекомендовалось и не считалось единственным вариантом.
Ваш опыт мне не интересен, для моих задач он еще и не релевантен.

N>Или Вы просто увидели код после какого-нибудь SmallC, который не умел оптимизировать в compile time даже вычисления констант, и делаете на этом основании выводы? Тогда Вам надо срочно освежать впечатления — как минимум на 20 последних лет.
Не нам, а вам, как говорится. Закройте ваши старые лохмотья назад в шкаф.

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

N>>>>6 байт вместо минимум 12 на 3 команды (прочитать в регистр, поставить бит, записать в память).
E>>>Но эти команды на самом деле не нужны — достаточно обычной двоичной логики.
N>>Расшифруйте.
E>Расшифровываю — читать дословно и понимать буквально.

Понятнее не стало.

N>>Это где-то документировано? Что надо, например, тратить загрузку 4-байтной константы 1 и затем её сдвигать, вместо (хотя бы) загрузки уже сдвинутого того же размера — это "коренная идеология CISC"?? Пока что я вижу только Вашу буйную фантазию, что это есть "коренная идеология CISC", и никаких подтверждений. Начиная ещё с S/360 для таких вещей старались брать готовые константы.
E>Коренная идеология CISC — "на каждый чих своя команда", остальное иллюстрация. И не надо поясничать на примере.

Нет такой идеологии у CISC. Идеология CISC все её активные времена была другой: 1) удобство программиста нижнего уровня через максимальное выражение идеи одной операции одной машинной командой и 2) ортогональность системы команд, независимость основной функции команды от метода адресации параметров, богатство методов адресации (включая крайне редкие, но изображающие какой-то особый случай). Предельные CISC это PDP-11, VAX-11, M68k. По сравнению с ними, S/360 (в RX и RS командах) и x86 это весьма недо-CISC: ну какой CISC, если только один операнд может быть в памяти, а остальное в регистрах? У S/360 память еще и не может быть приёмником. Вот команды типа EDMK у той же S/360 это уже суровейший CISC, да.

RISC потому и был революционным прорывом, что он был отказом от идеи "одно логическое действие — одна машинная команда", постановив "пусть он делает несчастный инкремент в 3 команды, да ещё и подумает, как их растянуть в потоке, чтобы не тормозили друг друга, зато в результате мы не будем терять десяток тактов на ровном месте". А итоговый OOO их примирил, хотя и дорогой ценой — все эти метки регистров, таблицы влияний и конвейеры тратят драгоценные джоули.

N>>Я работал из CISC'ов и близких к ним — с S/360 (в виде ЕС 10xx), PDP-11, 6502, 8080, x86. (Вот VAX'а не довелось пощупать, увы. И M68k не попался.) Нигде такого не рекомендовалось и не считалось единственным вариантом.
E>Ваш опыт мне не интересен, для моих задач он еще и не релевантен.

А мы не обсуждаем Ваши задачи.

N>>Или Вы просто увидели код после какого-нибудь SmallC, который не умел оптимизировать в compile time даже вычисления констант, и делаете на этом основании выводы? Тогда Вам надо срочно освежать впечатления — как минимум на 20 последних лет.
E>Не нам, а вам, как говорится. Закройте ваши старые лохмотья назад в шкаф.

Вы всерьёз верите в тотальную победу RISC? Это несмотря на то, что даже столь хвалимый Вами ARM среди всей этой братии самый не-рисковый, и на то, что на десктопах, серверах и в HPC он по-прежнему не поднимается выше пары случайных процентов?

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

E>>>>>Принцип очень прост — в современных реалиях обратная совместимость на уровне машинных команд со старыми процессорами не нужна.
N>>>>Скажите это авторам софта под Windows. Которого до сих пор до хрена и больше ещё с ранних 32-битных времён.
E>>>А им еще кто-то пользуется ?
N>>Знаете ли, да. Если не надевать на глаза шоры, которые не позволяют увидеть ничего кроме планшетов — то можно видеть много интересного. В том числе и корпоративный мир с его спецификой, и множество специфических отраслей, где сидят на разработках 50-летней давности и очень неохотно освежают их...
E>Корпоративный мир давно уже отходит в сторону от windows, хотя ваше нии врядли относится к корпоративному миру.

"Моё НИИ", если его так назвать, последние 15 лет работает исключительно с Unix. Но, в отличие от Вас, я вижу реальную картину в мире.
Да, те же смартфоно-планшеты заняли существенную часть, но только там, где хватает функциональности в объёме "прочитать почту — посмотреть видео — поредактировать в *office — послать котика в FB". Как только мы приходим куда-нибудь к десктопу и дальше — начинается x86.

E>>> Софт под виндовс в основном слишком монструозен и убог по функциональности.
N>>Это Вы по солитеру судите?
E>Назовите хотя бы один продукт под windows для которого это неверно.

Для начала определите критерии убогости и монструозности. Личный вкус не прокатит.

E>>>>>Про ясли начали вы. Так что про вас.
N>>>>Вы уже придумали, какая именно разновидность святого духа помогает выполнять одну команду за полтакта (а не 100 команд за 50 тактов)? Требуется ли для этого, например, икона Георгия-победоносца?
E>>>Хм, интересный переход в религиозные темы. Но я ориентируюсь на спецификации от производителей.
N>>Ну тогда Вам осталось сделать небольшой последний шаг — начать понимать, что же именно в них написано.
E>Но вам для этого надо начать хотя бы с языка.

Учитесь троллингу — это замечательно. Но лучше бы Вы вместо этого учили схемотехнику. Я Вас уже спрашивал — каким образом у Вас за полтакта команда прочитается из памяти (пусть даже из L1 кэша), декодируется и хотя бы начнёт исполняться?