Re[5]: Несколько замечаний об истории советской информатики - Образование и наука

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 последних лет.
Не нам, а вам, как говорится. Закройте ваши старые лохмотья назад в шкаф.

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

E>И у каждого GPU под 1000 процессоров, с частотой под гигагерц, гигабайты памяти доступны, и инструкции таковы, что даже синусы косинусы вычисляются аппаратно практически за такт.
Это не так, просто, если придется работать -- у ГПУ 4-8 железных камней, которые умеют делать симд 16-64 элементов. Также он довольно шустро метается с нитки на нитку, если нитка занимается чем то жолгим, например чтением из памяти, что и дает довольно выское количество параллельных процессов.

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

N>

N>...некоторыми фактами, которые противоречат насаждаемым либеральным псевдоисторическим клише в данной области.

про "клише" так и не понял, но хочу кинуть пару камней.
1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.
2) "мы делали гениальный прорывной проект, но... деньги закончились". это я слышал уже не раз и не два. бабло побеждает. ну да, технарям уже давно надо признать, что "гениальный прорывной проект" без политики (которая заключается или в поиске денег, или в поиске покровителей) — не выживет.
во

E>>Z80 — это CPU (в том числе и из спектрума). А вот советский его аналог — микросхема KP580BM80A. И Радио86К, Океан240, и проч. на его основе — где ?
E>KP580BM80A — это аналог intel 8080.
Z80 отличался от 8080 дополнительной (системной) страницей регистров и несколькими дополнительными командами.
В целом софт с Z80 нормально работал на KP580BM80A.

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

B>про "клише" так и не понял, но хочу кинуть пару камней.
B>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.

А в чем тут проявился тормоз в создании ЭВМ или как их называли тогда ЭСМ?
Вот сколько не смотрю на историю появления разных там первых МЭСМ и прочих, вижу что МЭСМ начала разрабатываться в 1948-м (!!!) году, не намного-то и позже США и никто разработки такого рода не тормозил ни тогда, ни в 50-х. Как раз в 60-х пошла идея, что нам проще слямзить на Западе, чем своё развивать.

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

LVV>При этом Непейвода сообщает. что наши были у Цузе и кое-что у него явно слямзили...

LVV>Как-то это не очень стыкуется с объявлением кибернетики лженаукой.

Тем не менее, статья такая была в БСЭ 50-х годов. Сам читал. К сожалению, сейчас доступа к той энциклопедии у меня нет, не могу привести точные координаты статьи. Возможно, ее объявили лженаукой для масс, а в узких кругах понимали все значение работ Тьюринга и других.

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

LVV>[q]
LVV>Москали и РЯД. К концу 60-х годов стало ясно, что необходимо переходить к новому поколению машин. Наработки были и в Пензе, и в Минске, и в Киеве. и в Новосибирске (все это по крайней мере). Но зазвездившийся и привыкший быть абсолютным монополистом ИТМВТ вместе с московской группой вокруг него взял заказ на разработку новой модели сам, желая ободрать идеи у всех остальных. Он потребовал документацию у них. Она пришла. Но по какой-то случайности (Берии уже не было и ответственность практически исчезла) везде не хватало по нескольку страниц, и, самое странное, решающих. ...
LVV> И почти все самостоятельные разработки были убиты. Впрочем, это полностью соответствовало духу развитого социализма, который на самом деле уже морально сдался и при котором безопасность и отсутствие рисков стали главным критерием для почти всех управленцев.

Однако, как точно автор обрисовал лицо развитого социализьма — желание "ободрать идеи у всех остальных" осталось, а вот Берии-то, чтоб это воплотить в жизнь уже нету. Ай-ай-ай, какая жалость.

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

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

B>>1) то, что кибернетика была объявлена лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.

P>Fixed

Неправильно. Кибернетика была действительно лженаукой, достигшей в СССР высшей степени развития.

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

E>>>Z80 — это CPU (в том числе и из спектрума). А вот советский его аналог — микросхема KP580BM80A. И Радио86К, Океан240, и проч. на его основе — где ?
E>>KP580BM80A — это аналог intel 8080.
E>Z80 отличался от 8080 дополнительной (системной) страницей регистров и несколькими дополнительными командами.
E>В целом софт с Z80 нормально работал на KP580BM80A.

Ерунда. Ты наверно запускал на Z80 софт, который был написан для i8080/KP580BM80A, переносил на родную платформу и радовался, что он работает, так?
Система команд у Z80 была кардинально расширена по сравнении с прототипом. И достаточно одной неподдерживаемой команды, чтобы программа не работала. Или ты думаешь, что i8080 просто пропускал незнакомые опкоды, выбирал знакомые и с ними работал как ни в чем не бывало?

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

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

B>>>про "клише" так и не понял, но хочу кинуть пару камней.
B>>>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.
M>>А в чем тут проявился тормоз в создании ЭВМ или как их называли тогда ЭСМ?
M>>Вот сколько не смотрю на историю появления разных там первых МЭСМ и прочих, вижу что МЭСМ начала разрабатываться в 1948-м (!!!) году, не намного-то и позже США и никто разработки такого рода не тормозил ни тогда, ни в 50-х. Как раз в 60-х пошла идея, что нам проще слямзить на Западе, чем своё развивать.

N>Тормоз был, например, в отсутствии плотного общения с западными коллегами, из-за чего хорошие идеи с трудом пробивались.

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

N>Как бы ни был гениален Лебедев, но машина с одним аккумулятором и 15 индексными регистрами это катастрофически перекошенный дизайн. А это ведь великая БЭСМ-6. Код превращался в сплошную загрузку и выгрузку аккумулятора.
N>Тут приходит S/360 с 16 почти эквивалентными регистрами для всех целей, и сравнение показывает (это был аргумент в дискуссиях за ЕС тех времён), что код на S/360 в ~3 раза короче эквивалента на БЭСМ-6. И это ещё не вспоминая, что последняя была 16-битной в стиле PDP-11 (виртуальная память формата "маленькое окно в большой мир"). Или та же тотальная двоичная иерархия размеров, которая упрощала многие вопросы дизайна чуть более чем полностью.
N>И это только уровень двоички. А дальше? Тут рассказывали про таблицы перевода, но для них требовались девочки, а не компилятор.

Я в реале не имел дела с БЭСМ или ЕС, поэтому не имею личных впечатлений. Тем не менее, от чтения разных мемуаров сложилось такое, что разным физикам и инженером намного лучше было работать с БЭСМ-6, чем с ЕС. ЕС еще и намного чаще ломалась.

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

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

LVV>>При этом Непейвода сообщает. что наши были у Цузе и кое-что у него явно слямзили...

LVV>>Как-то это не очень стыкуется с объявлением кибернетики лженаукой.

P>Тем не менее, статья такая была в БСЭ 50-х годов. Сам читал. К сожалению, сейчас доступа к той энциклопедии у меня нет, не могу привести точные координаты статьи.

http://flibusta.net/b/152655/read

В СССР после первоначального периода отрицания и сомнений утверждалось более естественное и содержательное определение К., включившее в нее все достижения, накопленные к тому времени в теории преобразования информации и управляющих систем. При этом особое внимание уделялось новым проблемам, возникающим в связи с широким внедрением ЭВМ в теорию управления и теорию преобразования информации.

P> Возможно, ее объявили лженаукой для масс, а в узких кругах понимали все значение работ Тьюринга и других.

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

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

Здравствуйте, 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 он по-прежнему не поднимается выше пары случайных процентов?

Непейвода Н Н:

Несколько раз мне приходилось читать курс истории информатики. Я хочу поделиться некоторыми фактами, которые противоречат насаждаемым либеральным псевдоисторическим клише в данной области. Кажется, часть из них в печати не встречалась. Конечно, те, кто не хотят знать ничего, потребуют письменных подтверждений. Но я учился у пионеров и работал вместе с классиками. Многое тогда они записывать не могли. Приводить буду лишь то, что мог перепроверить по крайне мере двум относительно независимым источникам, один из которых — непосредственный участник событий.

Ссылка

Оттуда же:

Оригинальные арзитектуры. Лично работал: Днепр, Сетунь, Мир, Русалка, Эльбрус, ПС-2000. Знаю о машинах в остаточных классах. Может что-то ещё было, не вспоминается. Но в начале 90-х Гайдар заявил: "Молодой России электронная промышленность не нужна. Все, что нужно, купим за нефть" И убили.

И еще:

Москали и РЯД. К концу 60-х годов стало ясно, что необходимо переходить к новому поколению машин. Наработки были и в Пензе, и в Минске, и в Киеве. и в Новосибирске (все это по крайней мере). Но зазвездившийся и привыкший быть абсолютным монополистом ИТМВТ вместе с московской группой вокруг него взял заказ на разработку новой модели сам, желая ободрать идеи у всех остальных. Он потребовал документацию у них. Она пришла. Но по какой-то случайности (Берии уже не было и ответственность практически исчезла) везде не хватало по нескольку страниц, и, самое странное, решающих. ...
И почти все самостоятельные разработки были убиты. Впрочем, это полностью соответствовало духу развитого социализма, который на самом деле уже морально сдался и при котором безопасность и отсутствие рисков стали главным критерием для почти всех управленцев.

И немного юмора:

Когда создана была машина БЭСМ-4, был поставлен вопрос о написании трансляторов. Ведущие московские программисты, вызванные в ВПК, резко протестовали. "Зачем нужно тратить столько сил и ресурсов? Нам программы девочки напишут" (смотри предыдущий пункт). Но выступил весьма полузнающий и амбициозный функционер из ЦК и заявил: "Я вам приоткрою большой секрет. Сейчас делается машина. которая будет исполнять миллион команд в секунду (имелась в виду БЭСМ-6). Что вам. миллион команд девочка напишет?" И было принято правильное решение делать трансляторы.

Как-то это не очень стыкуется с объявлением кибернетики лженаукой.
B>2) "мы делали гениальный прорывной проект, но... деньги закончились". это я слышал уже не раз и не два. бабло побеждает. ну да, технарям уже давно надо признать, что "гениальный прорывной проект" без политики (которая заключается или в поиске денег, или в поиске покровителей) — не выживет.
Деньги не кончаются только на оборону.
А на остальное — см. "грамотность" управленцев в технических вопросах.
А также замечание Непейводы об отсутствии Берии и ответственности

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

LVV>Оригинальные арзитектуры. Лично работал: Днепр, Сетунь, Мир, Русалка, Эльбрус, ПС-2000. Знаю о машинах в остаточных классах. Может что-то ещё было, не вспоминается. Но в начале 90-х Гайдар заявил: "Молодой России электронная промышленность не нужна. Все, что нужно, купим за нефть" И убили.
Так это Гайдар оказывается является причиной того, что до 90-х даже спектрум был мечтой? А то ведь массово спектрум совместимые в промышленных масштабах по приемлемой цене появились именно в 90-е, если что. Именно при Гайдаре компы стали доступны, и это были компы собственного производства, хоть и не оригинальной архитектуры. Из импорта там был только Z80 и AY. А до 90-х компьютеры домашние были у ОЧЕНЬ немногих, и то их паяли чаще всего сами.

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

E>Z80 — это CPU (в том числе и из спектрума). А вот советский его аналог — микросхема KP580BM80A. И Радио86К, Океан240, и проч. на его основе — где ?
Компы на аналогах буржуйских процессоров с достаточно оригинальной архитектурой да, они выпускались в 80-е. Но:
1) Из за оригинальной архитектуры с софтом было ОЧЕНЬ плохо;
2) Они были очень недешевые, и при этом их еще и не купить было.

Радио-86 РК — это комп для самостоятельной сборки. Без соответствующей квалификации ты хрен сделаешь, чтоб он заработал. Кроме того, микросхемы для его сборки тоже достать очень и очень непросто было. И это РК, который специально проектировался чтоб микросхем дефицитных было как можно меньше. До РК был еще Микро-80, практически полный его аналог, там вообще микросхем было под сотню. Тех, кто собирал компы самостоятельно — их было весьма и весьма мало.

Лично мне по архитектуре весьма понравился Орион-128, хоть и не был я никогда его обладателем. Довольно грамотно сделал, ничего лишнего, максимально дешев. Лично мне он архитектурно нравится гораздо больше спектрумов, причем даже крутых спектрумов, вроде АТМ-Турбо. Но вот только он проектировался тогда, когда эпоха 8-битов уже давно ушла. И то, что в 1990м году было предложено собирать именно его, как раз весьма неплохо говорит об уровне возможностей электронной промышленности и о доступной элементной базе. И даже его собрать было весьма и весьма непросто, если что, по сложности примерно как спектрум. Вот только на спектрум клонах софта было завались, потому выбор был очевиден.

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

E>>>Z80 — это CPU (в том числе и из спектрума). А вот советский его аналог — микросхема KP580BM80A. И Радио86К, Океан240, и проч. на его основе — где ?
E>>KP580BM80A — это аналог intel 8080.
E>Z80 отличался от 8080 дополнительной (системной) страницей регистров и несколькими дополнительными командами.

Z80 хотя и сделан на основе 8080, но система команд у него совершенно другая. Не говоря уже о таких "мелочах", как одно питание вместо трех. Поэтому нельзя говорить о том, что аналог Z80 — KP580BM80A.

E>В целом софт с Z80 нормально работал на KP580BM80A.

Не мог софт Z80 работать на 8080. Разве что, если его перетранслировать из исходников.

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

B>>про "клише" так и не понял, но хочу кинуть пару камней.
B>>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.

A>Если ты будешь часто повторять глупости (или одну глупость, но часто), то к тебе будут соответсвующе относиться.
A>Не qwerty посмотри.

Лучше на твое мнение насчет паспортов колхозников.

А что не так с лженаукой кибернетикой? Это Гайдар придумал? А я помню, что слышал об этом еще в школе.

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

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

B>>>про "клише" так и не понял, но хочу кинуть пару камней.
B>>>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.

A>>Если ты будешь часто повторять глупости (или одну глупость, но часто), то к тебе будут соответсвующе относиться.
A>>Не qwerty посмотри.

Q>Лучше на твое мнение насчет паспортов колхозников.

Ну вообще-то я имел в виду твоё мнение по поводу курса рубля и рыночной экономики.
Но с паспортами тоже смешно получилось. И это тоже сыграло против твоей репутации.

Q>А что не так с лженаукой кибернетикой? Это Гайдар придумал? А я помню, что слышал об этом еще в школе.

Да, это Гайдар придумал.
Вот в этом ты весь. Вопиющая безграмотность. Ты бы хоть Википедидию почитал.

ru.wikipedia.org/wiki/Винер,_Норберт

В СССР перевод «Кибернетики» Винера на русский язык, под редакцией Г. Н. Поварова, вышел в 1958 году, второе издание (с учётом расширенного американского издания) — в 1968 году, потом оно неоднократно переиздавалось.

"Слышал он". Ага. От таких же как сам.

Q>Z80 хотя и сделан на основе 8080, но система команд у него совершенно другая. Не говоря уже о таких "мелочах", как одно питание вместо трех. Поэтому нельзя говорить о том, что аналог Z80 — KP580BM80A.
Система команд аналогичная но расширеная дополнительными командами, у меня книжка даже где-то сохранилась, пожалуй я поищу и сравню.
Питание — совершенно не при чем, хоть трехфазное — софту пофигу.

E>>В целом софт с Z80 нормально работал на KP580BM80A.
Q>Не мог софт Z80 работать на 8080. Разве что, если его перетранслировать из исходников.
Значит у меня батхерд.

E>>Z80 отличался от 8080 дополнительной (системной) страницей регистров и несколькими дополнительными командами.
E>>В целом софт с Z80 нормально работал на KP580BM80A.
E>Наоборот, софт с Intel 8080 нормально работал на Z80. Обратно ни хрена. Кроме того, ассемблерные мнемоники отличались у Z80 и Intel8080, хотя транслировались в одинаковые коды.
Различные мнемоники не влияют не что, главное чтобы двоичный код был одинаковым и деле тоже самое.

E>Этих дополнительных команд у z80 было более чем дохрена. Там и дополнительные режимы адресации, дополнительные просто регистры, а также дополнительные теневые регистры.
Дополнительных команд — несколько штук (но я еще раз гляну, может забыл), дополнительных регистров всего два, еще дополнительная (теневая, системная) страница регистров — но прикладной софт не должен был её юзать по замыслу.

E>Кроме программной части, Z80 был попроще в эксплуатации. В частности ему требовалось одно напряжение питания, а не 3, как в intel8080. Также число тактов на команду в Z80 и intel8080 разное, z80 работает побыстрее. И кроме этого тактовая частота z80 будет поболее, раза эдак в 2.
Это все к делу не относится — медленее, быстрее, трехфазное питание, и прочее — софту пофигу на это.

Q>>Z80 хотя и сделан на основе 8080, но система команд у него совершенно другая.
Даже книжку откапывать не пришлось, вот сравнительная таблица — система команд одинаковая, но расширеная. Дополнительные команды — это все-то манипуляция с дополнительными регистрами и тесты битов.

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

E>>Этих дополнительных команд у z80 было более чем дохрена. Там и дополнительные режимы адресации, дополнительные просто регистры, а также дополнительные теневые регистры.
E>Дополнительных команд — несколько штук (но я еще раз гляну, может забыл), дополнительных регистров всего два, еще дополнительная (теневая, системная) страница регистров — но прикладной софт не должен был её юзать по замыслу.
Их там не несколько штук, а несколько десятков штук. А на деле — чуть ли не в 2 раза больше. Теневая страница регистров используется софтом вовсю, ибо когда каждый такт на счету, никто не будет отказываться от дополнительных регистров. И даже если не используется. Там есть команды относительного перехода относительно текущего счетчика команд. на +-128 байт, сама команда двухбайтовая. В z80 очень активно используется. Если что, в i8080 ничего такого нет, переход там всегда 3 байта занимает (если не считать команду программного прерывания RST), и одной этой новой команды достаточно чтоб ни черта не работало. Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.

Про дополнительные регистры. 2 то их два. Но это не просто регистры, это специализированные регистры для поддержки дополнительного способа адресации.
Там система команд расширена очень значительно, в результате код на z80 часто довольно значительно компактнее кода на i8080. А в условиях охрененно ограниченной и дорогой памяти это было важно.

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

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

LVV>>Оригинальные арзитектуры. Лично работал: Днепр, Сетунь, Мир, Русалка, Эльбрус, ПС-2000. Знаю о машинах в остаточных классах. Может что-то ещё было, не вспоминается. Но в начале 90-х Гайдар заявил: "Молодой России электронная промышленность не нужна. Все, что нужно, купим за нефть" И убили.
E>Так это Гайдар оказывается является причиной того, что до 90-х даже спектрум был мечтой? А то ведь массово спектрум совместимые в промышленных масштабах по приемлемой цене появились именно в 90-е, если что. Именно при Гайдаре компы стали доступны, и это были компы собственного производства, хоть и не оригинальной архитектуры. Из импорта там был только Z80 и AY. А до 90-х компьютеры домашние были у ОЧЕНЬ немногих, и то их паяли чаще всего сами.

Какую-то ерунду, ей богу говорите. В начале 90-х просто был период, когда предприятия радио- и электронной промышленности еще не развалились и модно было клепать клоны спектрумов, сег и прочего такого. При этом строили все такие предприятия до Гайдара и как раз в 90-91 многие из них проходили модернизацию.

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

E>Про дополнительные регистры. 2 то их два. Но это не просто регистры, это специализированные регистры для поддержки дополнительного способа адресации.
E>Там система команд расширена очень значительно, в результате код на z80 часто довольно значительно компактнее кода на i8080. А в условиях охрененно ограниченной и дорогой памяти это было важно.

Это всё интересно, но к советской информатике это уже не имеет отношения.

E>Их там не несколько штук, а несколько десятков штук. А на деле — чуть ли не в 2 раза больше.
Эти команды — манипуляция с битами и с дополнительными регистрами, без них вполне себе жить можно, а при надобности и пропатчить эти места при загрузке (но это уже потом стало широко использоваться). Про адресацию я не вспомнил — да.
E>Теневая страница регистров используется софтом вовсю, ибо когда каждый такт на счету, никто не будет отказываться от дополнительных регистров. И даже если не используется.
Теневая страница регистров была придумана разработчиками Z80 исключительно для того чтобы не сохранять и стейт регистров при системных вызовах и востанавливать его потом назад. Прикладной програме туда нельзя было, так что это ничего не меняет.

E>Там есть команды относительного перехода относительно текущего счетчика команд. на +-128 байт, сама команда двухбайтовая. В z80 очень активно используется. Если что, в i8080 ничего такого нет, переход там всегда 3 байта занимает (если не считать команду программного прерывания RST), и одной этой новой команды достаточно чтоб ни черта не работало.
В i8080 команды перехода — относительные, относительно PC — нынешний короткий джамп на x86 со знаковым 16 битным смещением, это он и есть.

E>Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.
Ну а можно было и с битовой табличкой патчить адреса — это в принципе до сих пор так и осталось, хотя использовалось в последний раз в DOS.

E>Про дополнительные регистры. 2 то их два. Но это не просто регистры, это специализированные регистры для поддержки дополнительного способа адресации.
E>Там система команд расширена очень значительно, в результате код на z80 часто довольно значительно компактнее кода на i8080. А в условиях охрененно ограниченной и дорогой памяти это было важно.
Ну ты сам посмотри — дополнительных команд только работы с двумя доп регистрами, манипуляции с битами, и, еще что-то по мелочи и всё.

E>В i8080 команды перехода — относительные, относительно PC — нынешний короткий джамп на x86 со знаковым 16 битным смещением, это он и есть.
Так, это я кажется наврал, опкод у x86 другой.

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

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

E>Это ни хрена не мелочи. Манипуляции с битами очень активно используются на практике. Это не современные компы, когда можно фигачить различный код в зависимости от того, поддерживаются ли определенные команды или нет. А в то время память была ограничен, каждый байтик был на счету, потому пользовались всеми возможностями, и затачивали под конкретный процессор. И писали сразу на асме.
В своё время я писал для Океана240 (там как раз KP580BM80A) и кое что перепаивал. Но по прежнему и до сих пор считаю, что персональные команды для манипуляции с одиночными битами не нужны.

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

A>Это всё интересно, но к советской информатике это уже не имеет отношения.
Это все к тому, что массовая советская информатика для простых людей — это клоны pdp11 и intel8080. А самая массовая — это были вообще программируемые калькуляторы, да и те хрен купишь. И если в буржундиях массово это все появилось в начале 80-х годов, то в СССР начало что то двигаться в начале 90-х.

Какие то отдельные разработки, заслуживающие внимания — да, были. Но именно компьютерной революции СССР не застал вообще, это случилось уже в России.

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

Q>>Z80 хотя и сделан на основе 8080, но система команд у него совершенно другая. Не говоря уже о таких "мелочах", как одно питание вместо трех. Поэтому нельзя говорить о том, что аналог Z80 — KP580BM80A.

E>Питание — совершенно не при чем, хоть трехфазное — софту пофигу.

Это означает, что его нельзя назвать аналогом. Аналог — это когда впаиваешь его вместо оригинала и он работает точно так же. Так вот аналог KP580BM80A — это 8080, а Z80 — это совершенно другой процессор.

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

Q>>>Z80 хотя и сделан на основе 8080, но система команд у него совершенно другая.
E>Даже книжку откапывать не пришлось, вот сравнительная таблица — система команд одинаковая, но расширеная. Дополнительные команды — это все-то манипуляция с дополнительными регистрами и тесты битов.

Значит меня сбили с толку мнемоники — они другие, поэтому я думал что и система команд другая.

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

A>Ну вообще-то я имел в виду твоё мнение по поводу курса рубля и рыночной экономики.

А по этому поводу тебе лучше вообще скромно помалкивать.

Q>>А что не так с лженаукой кибернетикой? Это Гайдар придумал? А я помню, что слышал об этом еще в школе.

A>Да, это Гайдар придумал.
A>Вот в этом ты весь. Вопиющая безграмотность. Ты бы хоть Википедидию почитал.

Альфа, пойми наконец, что мне не надо читать википедию потому что я тогда жил и читал о том, что цифровая электроника долгое время не развивалась (читай: не копировалась) как раз из-за того, что некоторые умники объявили кибернетику буржуазной лженаукой. И спорить можно лишь о том правда ли там писалась или нет, но это писалось в советских журналах 70-х годов, я это читал лично! А дыма без огня, как известно, не бывает.

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

E>В своё время я писал для Океана240 (там как раз KP580BM80A) и кое что перепаивал. Но по прежнему и до сих пор считаю, что персональные команды для манипуляции с одиночными битами не нужны.
Это сейчас они не нужны. А тогда они были нужны и еще как:
1) Для вывода чего то на экран
2) В условиях ограничений памяти, когда каждый байт на счету, в один байт упаковывали достаточно много флагов сразу. Сейчас уже такими техниками не пользуются.

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

Не следует то время сравнивать с текущим. Сейчас на ассемблере практически никто не пишет. Уже даже на GPU на плюсах программируют. И у каждого GPU под 1000 процессоров, с частотой под гигагерц, гигабайты памяти доступны, и инструкции таковы, что даже синусы косинусы вычисляются аппаратно практически за такт. А тогда даже целочисленное умножение считалось крайне дорогой операцией, приходилось подпрограммы писать для этого дела.

E>>В своё время я писал для Океана240 (там как раз KP580BM80A) и кое что перепаивал. Но по прежнему и до сих пор считаю, что персональные команды для манипуляции с одиночными битами не нужны.
E>Это сейчас они не нужны. А тогда они были нужны и еще как:
E>1) Для вывода чего то на экран
E>2) В условиях ограничений памяти, когда каждый байт на счету, в один байт упаковывали достаточно много флагов сразу.
Много битовых флагов в одном байте или слове разруливаются другими техниками. А персональные команды работы с одиночными битами — это мрачные отголоски CISC подхода, который слава богу, уже помер.
История уже поставила все точки на i.

E>Сейчас уже такими техниками не пользуются.
Пользуются (Вы скорее всего просто не в курсе), и очень активно, но команды для персональной работы с одним битом не нужны.

E>Ну занимает булев флаг порядка 50 байт, да и черт с ним, памяти достаточно. Нужно битовый массив — так и хреначим массив объектов, которые являются оберткой над целочисленным типом. А тогда даже байт на булев флаг считалось крайним расточительством. Потому упаковывали все как только можно. А тогда было хреново одновременно и с объемом памяти, и со скоростью процессора. Потому на вот такие дополнительные команды молились, ибо они значительно ускоряли работу и делали программу более компактной, а значит можно было больше данных в памяти уместить.
Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.

E>Не следует то время сравнивать с текущим. Сейчас на ассемблере практически никто не пишет.
Пишут и очень много, но не везде, а там где требуется. Во всяких embedded — еще как пишут.

E>Уже даже на GPU на плюсах программируют.
На расширеном подмножестве С, если быть точным. У GPU нет стека (вообще нет) поэтому там не очень традиционный подход.

E>И у каждого GPU под 1000 процессоров, с частотой под гигагерц, гигабайты памяти доступны, и инструкции таковы, что даже синусы косинусы вычисляются аппаратно практически за такт.
Это все немного не так, но да ладно.

E>А тогда даже целочисленное умножение считалось крайне дорогой операцией, приходилось подпрограммы писать для этого дела.
Целочисленое умножение — не самая медленая операция, есть еще и деление. Ну а подпрограммы писались потому что соответсвующая команда целочисленого умножения отсутсвовала. Сейчас, кстати, тоже пишут подпрограммы для целочисленого умножения и деления для типов большей разрядности чем может обрабатывать CPU, так что ничего особо не поменялось.

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

B>1) то, что кибернетика была объявлена лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.

Fixed

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

E>Много битовых флагов в одном байте или слове разруливаются другими техниками. А персональные команды работы с одиночными битами — это мрачные отголоски CISC подхода, который слава богу, уже помер.
E>История уже поставила все точки на i.
Вот только что intel8080, что z80 — это все вполне себе CISC. Про x86, который снаружи живее всех живых даже говорить смысла нет — там сейчас сверхсложная система команд снаружи, хоть и RISC внутри, уже вообще без поллитра не разобраться. Как то массовых производительных RISC процессоров сейчас не ахти. Рулят то немеряно в плане энергоэффективности, но в плане скорости все пока слабо. И что то я не наблюдаю перспектив смерти x86. Может быть Apple то и перейдет с интела на RISC, вроде планы есть у них, да и опыт перехода имеется. Майкрософт попыталась, и пока не получается у нее, RT планшеты не очень покупают, предпочитают атомы а не АРМ. Но пока x86 архитектура не загибается, лет 5-10 еще точно протянет.

E>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
Ха, x86. Так это минимум 16 битный процессор, а сейчас уже 64 битные. И для скорости там выравнивание применяют по границу слова (а для 64 бит и двойного слова кажись), что расточительно черти как. Естественно, что при такой битности сейчас RISC рулит, ибо декодирование команд тривиально. Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно. А вот 16 битные RISC были, тот же PDP-11. Ну и как с размером программ на БК-0010? Тот же z80 это все рвет как тузик грелку, несмотря на 8 битность.

E>>Много битовых флагов в одном байте или слове разруливаются другими техниками. А персональные команды работы с одиночными битами — это мрачные отголоски CISC подхода, который слава богу, уже помер.
E>>История уже поставила все точки на i.
E>Вот только что intel8080, что z80 — это все вполне себе CISC. Про x86, который снаружи живее всех живых даже говорить смысла нет — там сейчас сверхсложная система команд снаружи, хоть и RISC внутри, уже вообще без поллитра не разобраться. Как то массовых производительных RISC процессоров сейчас не ахти. Рулят то немеряно в плане энергоэффективности, но в плане скорости все пока слабо. И что то я не наблюдаю перспектив смерти x86.
При чём здесь смерть x86 ? Речь идет о том что CISC в процессе эволюции CPU была отвергнута и похоронена. И даже Intel со своей x86 перешел на RISC микроядро транслируя CISC команды x86 в RISC подрограммы.

Но пока x86 архитектура не загибается, лет 5-10 еще точно протянет.
E>Она внутри RISC уже давно. Аппаратный транслятор там для совместимости.

E>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
E>Ха, x86. Так это минимум 16 битный процессор, а сейчас уже 64 битные.
Я имел ввиду 32 битный x86 (а он опкодами от 16 битового не отличается, кстати).

E>И для скорости там выравнивание применяют по границу слова (а для 64 бит и двойного слова кажись), что расточительно черти как. Естественно, что при такой битности сейчас RISC рулит, ибо декодирование команд тривиально.
Код x86 не выравнивается ни по каким границам.

E>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
1) Z80 и i8080 — это 16 битовые процессоры. 2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.

E>А вот 16 битные RISC были, тот же PDP-11.
WTF ?

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

E>1) Z80 и i8080 — это 16 битовые процессоры.
Это я опять сморозил в пылу.

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

Да ежшкин код, чтож такое. Все нафиг перепутал. Ну да другая там не x86 микросхема была, совместима с PDP-11. Но PDP-11 ни разу не RISC.

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

E>>1) Z80 и i8080 — это 16 битовые процессоры.
E>Это я опять сморозил в пылу.

Это потому, что там регистры в пары можно было объединять. Или я наврал?

P>Это потому, что там регистры в пары можно было объединять. Или я наврал?

Ну да можно, но сама шина 8 битовая.

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

E>При чём здесь смерть x86 ? Речь идет о том что CISC в процессе эволюции CPU была отвергнута и похоронена. И даже Intel со своей x86 перешел на RISC микроядро транслируя CISC команды x86 в RISC подрограммы.
Система команд у x86 по прежнему CISC. Что там внутри RISC ядро — это детали. Комбинированный подход на данный момент рулит неимоверно. Учитывая что до сих пор добавляют новые инструкции, жить CISC будет еще долго.

E>Код x86 не выравнивается ни по каким границам.
Его можно не выравнивать. Но невыровненный код работает медленнее. Потому для скорости его как раз выравнивают. Я, привыкший к 64 килобайтам, когда экономить нужно каждый байт, был в шоке, когда об этом узнал.

E>1) Z80 и i8080 — это 16 битовые процессоры. 2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
У RISC внутри очень легкий для декодирования и унифицированный формат команды. Одинаковое количество байт на команду там, в частности. Причем даже с учетом перехода по адресу, все равно будет одинаковое количество байт. В 2 байта уложиться можно, если памяти порядка 64к. В 1 ну никак не пролезть. Потому в i8080 длина команды от 1 до 3 байт включительно. В z80 до 5 или даже 6, не помню уже. В современных RISC, например в MIPS — команда 32 бита. Любая команда.

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

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

P>Это потому, что там регистры в пары можно было объединять. Или я наврал?

Да, можно.

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

E>Да ежшкин код, чтож такое. Все нафиг перепутал. Ну да другая там не x86 микросхема была, совместима с PDP-11. Но PDP-11 ни разу не RISC.
Ну да, там CISC, но де факто очень близко к RISC. В 16 бит команду RISC не получится впихнуть. Формат команды там весьма простой и унифицированный, единственное отличие от RISC — это команда перехода, она не влезает в 2 байта. А возможно еще исключения есть, не вспомню уже.

E>>При чём здесь смерть x86 ? Речь идет о том что CISC в процессе эволюции CPU была отвергнута и похоронена. И даже Intel со своей x86 перешел на RISC микроядро транслируя CISC команды x86 в RISC подрограммы.
E>Система команд у x86 по прежнему CISC. Что там внутри RISC ядро — это детали. Комбинированный подход на данный момент рулит неимоверно. Учитывая что до сих пор добавляют новые инструкции, жить CISC будет еще долго.
Это legacy, оно будет жить пока есть спрос на совместимость. Но это спрос спадает.

E>>Код x86 не выравнивается ни по каким границам.
E>Его можно не выравнивать. Но невыровненный код работает медленнее. Потому для скорости его как раз выравнивают. Я, привыкший к 64 килобайтам, когда экономить нужно каждый байт, был в шоке, когда об этом узнал.
Можно взять любой дизассемблер и посмотреть — не выравнивается в 100% случаев, что я видел — нету nop-ов между командами. Данные в памяти выравниваются.

E>>1) Z80 и i8080 — это 16 битовые процессоры. 2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
E>У RISC внутри очень легкий для декодирования и унифицированный формат команды. Одинаковое количество байт на команду там, в частности. Причем даже с учетом перехода по адресу, все равно будет одинаковое количество байт. В 2 байта уложиться можно, если памяти порядка 64к. В 1 ну никак не пролезть. Потому в i8080 длина команды от 1 до 3 байт включительно. В z80 до 5 или даже 6, не помню уже. В современных RISC, например в MIPS — команда 32 бита. Любая команда.
Да вполне простой RISC укладывается в 1 байт. Но разговор был не том. Если взять один и тот же скомпилированый код, то 32 бит версия для x86 будет _существенно_ длинше чем аналогичная версия для ARM32. Вот и экономия памяти.

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

E>Клон К1810ВМ86 да, производился, и бытовые компы на нем были. Но даже по сравнению с БК они были редкостью.
EC1841 довольно распространен был, но это уже в другое время, сильно позже чем мы начали разговор.

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

>язык символических обозначений, позволявший писать программы в машинных кодах как будто на языке более высокого уровня. чем Алгол, ЯЛС или Фортран. Но переводили в коды эти программы девочки-техники. Для перевода достаточно было иметь таблицы двоичных соответствий кодам команд и адресам переменных.

В переводе на современную терминологию — ассемблер. Который, оказывается, более высокого уровня, чем Алгол и Фортран...

Подобные заявления автора существенно подрывают доверие к его тексту. Впрочем, и без них доверия немного.

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

E>>Клон К1810ВМ86 да, производился, и бытовые компы на нем были. Но даже по сравнению с БК они были редкостью.
E>EC1841 довольно распространен был, но это уже в другое время, сильно позже чем мы начали разговор.

ЕС-1840/41, Искра-1030. Но они считались профессиональными, а не бытовыми.

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

E>>>Код x86 не выравнивается ни по каким границам.
E>>Его можно не выравнивать. Но невыровненный код работает медленнее. Потому для скорости его как раз выравнивают. Я, привыкший к 64 килобайтам, когда экономить нужно каждый байт, был в шоке, когда об этом узнал.
E>Можно взять любой дизассемблер и посмотреть — не выравнивается в 100% случаев, что я видел — нету nop-ов между командами. Данные в памяти выравниваются.

Видимо, Вы смотрели что-то очень древнее, или явно оптимизированное под сокращение размера. Если попросить современный компилятор сгенерировать код с обычными уровнями оптимизации (не какие-нибудь -Os для уменьшения размера), входные точки функций и даже точки начала тела цикла будут выровнены на границу 16 байт. Остаток забивается разными nop'ами. Вот, например, тест xorshift'а, компилятор — clang:

0000000000400610 <xor_init0>:
  400610:       55                      push   %rbp
  400611:       48 89 e5                mov    %rsp,%rbp
  400614:       c7 07 15 cd 5b 07       movl   $0x75bcd15,(%rdi)
  40061a:       c7 47 04 e5 55 9a 15    movl   $0x159a55e5,0x4(%rdi)
  400621:       c7 47 08 b5 3b 12 1f    movl   $0x1f123bb5,0x8(%rdi)
  400628:       c7 47 0c 33 13 49 05    movl   $0x5491333,0xc(%rdi)
  40062f:       5d                      pop    %rbp
  400630:       c3                      retq   
  400631:       66 66 66 66 66 66 2e    data32 data32 data32 data32 data32 nopw 
%cs:0x0(%rax,%rax,1)
  400638:       0f 1f 84 00 00 00 00 
  40063f:       00 

0000000000400640 <xor_next>:
  400640:       55                      push   %rbp
  400641:       48 89 e5                mov    %rsp,%rbp
[...]
  40066c:       89 47 0c                mov    %eax,0xc(%rdi)
  40066f:       5d                      pop    %rbp
  400670:       c3                      retq   
  400671:       66 66 66 66 66 66 2e    data32 data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
  400678:       0f 1f 84 00 00 00 00 
  40067f:       00 

0000000000400680 <main>:
  400680:       55                      push   %rbp
  400681:       48 89 e5                mov    %rsp,%rbp
[...]
  400735:       83 7d d0 00             cmpl   $0x0,-0x30(%rbp)
  400739:       7e 63                   jle    40079e <main+0x11e>
  40073b:       bb 01 00 00 00          mov    $0x1,%ebx
  400740:       41 89 c4                mov    %eax,%r12d
  400743:       66 66 66 66 2e 0f 1f    data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
  40074a:       84 00 00 00 00 00 
  400750:       45 89 f5                mov    %r14d,%r13d
  400753:       41 c1 e5 0b             shl    $0xb,%r13d

этот пример получился особо хорошим тем, что у двух функций код заканчивается на байте с адресом xxx0, до следующей границы 16 байт аж 15 оных — и вместо них вставляется какая-то ерунда, лишь бы процессор воспринял это как нормальную команду.

Такое поведение сейчас открыто напрямую рекомендовано руководствами по оптимизации и Intel, и AMD.

E>Да вполне простой RISC укладывается в 1 байт. Но разговор был не том. Если взять один и тот же скомпилированый код, то 32 бит версия для x86 будет _существенно_ длинше чем аналогичная версия для ARM32. Вот и экономия памяти.

Не на любых задачах. Но в целом такая тенденция, наверно, есть. Особенно в ix64, где кошмар с размерами констант в командах.

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

E>>При чём здесь смерть x86 ? Речь идет о том что CISC в процессе эволюции CPU была отвергнута и похоронена. И даже Intel со своей x86 перешел на RISC микроядро транслируя CISC команды x86 в RISC подрограммы.
E>Система команд у x86 по прежнему CISC. Что там внутри RISC ядро — это детали. Комбинированный подход на данный момент рулит неимоверно. Учитывая что до сих пор добавляют новые инструкции, жить CISC будет еще долго.

Угу. За счёт этого можно продолжать расширять систему команд. Система, построенная, как в типичном RISC, на это мало способна. Можно, конечно, придумывать хаки (например, так, что при 1111 в старших битах это часть продолжения предыдущей команды и потому сразу не разбирается, а разборка откладывается до прояснения сути предыдущей команды). Но 1) это хаки, 2) я такого пока не видел в реальных разработках.

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

B>>про "клише" так и не понял, но хочу кинуть пару камней.
B>>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.

M>А в чем тут проявился тормоз в создании ЭВМ или как их называли тогда ЭСМ?
M>Вот сколько не смотрю на историю появления разных там первых МЭСМ и прочих, вижу что МЭСМ начала разрабатываться в 1948-м (!!!) году, не намного-то и позже США и никто разработки такого рода не тормозил ни тогда, ни в 50-х. Как раз в 60-х пошла идея, что нам проще слямзить на Западе, чем своё развивать.

1. кибернетика отношения к информатике не имеет, это у насм всё путают. посмотрите названия книг виннера хотя бы. кибернетика шла вразрез с закостеневшей марксистской философией, вот её и клеймили

2. у нас одновременно появилось 2 машины с неймановской архитектурой — в москве и киеве, причём независимо разработанных, чуть раньше такая машина появилась в англии, больше нигде в европе их ещё не было. англичане ездили на неймановские ленкции и разрабатывали свою маишу по американсчким ллекалам. я полагаю, что и наши две машины были сделаны по лекциям неймана, благо что они были достаточно массовыми и туда агебты кгб могли проникнуть. иначе тружно объяснить как сразу два коллектива независимо додумались до того чтобы пропустить ошибки, сопутствовавшие разработке ENIAC

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

Q>Альфа, пойми наконец, что мне не надо читать википедию потому что я тогда жил и читал о том, что цифровая электроника долгое время не развивалась (читай: не копировалась) как раз из-за того, что некоторые умники объявили кибернетику буржуазной лженаукой. И спорить можно лишь о том правда ли там писалась или нет, но это писалось в советских журналах 70-х годов, я это читал лично! А дыма без огня, как известно, не бывает.

а автомобилей собственных тоже из-за этого не было? или масла в магазинах? в ссср активно развивалось то что нужно обронке. свперкомпьютеры там были не на мировом уровне, но близком. а чем скромнее машины, тем больше отставание. к компам для дома относились точно так же как автомобилям. БК-0010 в 89-м году стоил 600 рублей, т.е. 3 месячные зарплаты

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

E>Вот только что intel8080, что z80 — это все вполне себе CISC. Про x86, который снаружи живее всех живых даже говорить смысла нет — там сейчас сверхсложная система команд снаружи, хоть и RISC внутри, уже вообще без поллитра не разобраться. Как то массовых производительных RISC процессоров сейчас не ахти.

из популярных сейчас архитектур 2 cisc — ibm z и x86, 3 risc — power, arm, mips, 1 epic (fail)

при этом cisc/epic выжили исключительно благодаря грузу совместимости/финансовой мощи ibm&intel. а самостоятельно прлибвшие себе дорогу mips&arm — это только risc. если вспомнить, то alpha и hp pa были закрыты тоже по маркетинговым причинам, обходя на тот момент конкурентов по производительности

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

E>А вот 16 битные RISC были, тот же PDP-11.

ага, как насчёт mov (r6)+, -(r5) ?

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

E>1) Z80 и i8080 — это 16 битовые процессоры.

16-битные там от силы сложения подерживались. этим в общем-то и определяют 8 или 16-битный процессор

2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.

в risc команды фиксированного размера, включающие код команды, номера гегистров, с котолрыми она работает, режимы адртесации и прочее по мелочи. обычно это 32 бита. есть arm thumb, там размер команды 2/4 байта

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

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

это клон микропроцессора LSI-11

E>Клон К1810ВМ86 да, производился, и бытовые компы на нем были. Но даже по сравнению с БК они были редкостью.

ЕС-1840 стоила тысячи рублей так что на домашний комп никак не тянула

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

>>язык символических обозначений, позволявший писать программы в машинных кодах как будто на языке более высокого уровня. чем Алгол, ЯЛС или Фортран. Но переводили в коды эти программы девочки-техники. Для перевода достаточно было иметь таблицы двоичных соответствий кодам команд и адресам переменных.

девочки-ассемблеры

Зато только за счёт конструкции системы команд CISC допускает неограниченное развитие, а RISC — нет. Вон через VEX префикс добавили ещё один аргумент командам. Как ты такое сделаешь на RISC?

E>Но пока x86 архитектура не загибается, лет 5-10 еще точно протянет.

Если будет продолжаться бурное развитие аппаратных возможностей — она сможет тянуть вечно.
Вот если они подойдут к порогу остановки — тогда начнётся поиск альтернатив. Собственно, он уже ведётся — каждый следующий техпроцесс сложнее вытягивать. Но покажите мне ARM с аналогом AVX2?

E>>И для скорости там выравнивание применяют по границу слова (а для 64 бит и двойного слова кажись), что расточительно черти как. Естественно, что при такой битности сейчас RISC рулит, ибо декодирование команд тривиально.
E>Код x86 не выравнивается ни по каким границам.

См. соседнее сообщение.

E>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>1) Z80 и i8080 — это 16 битовые процессоры. 2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.

Reduced в RISC не потому, что команд мало или они короткие, а потому, что они простые. Никаких сложностей стиля mov ofs(%7), @(%2)+ в PDP-11. Всё исполнение должно уложиться на стандартные 5 тактов (в среднем по архитектурам). При этом ничто не мешает создать 100500 команд под каждый тонкий частный случай.

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

LVV>Оттуда же:
LVV>

LVV>Оригинальные арзитектуры. Лично работал: Днепр, Сетунь, Мир, Русалка, Эльбрус, ПС-2000. Знаю о машинах в остаточных классах. Может что-то ещё было, не вспоминается. Но в начале 90-х Гайдар заявил: "Молодой России электронная промышленность не нужна. Все, что нужно, купим за нефть" И убили.

...
Только в начале 90-х Гайдар мог заявить только "денег нет и взять неоткуда." Вспомните, сколько тогда стоила нефть.

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

BZ>ЕС-1840 стоила тысячи рублей так что на домашний комп никак не тянула
Были и домашнего применения. Например Ассистент-128, Поиск.

Цена да, ого го. Ну тут у родителей некоторых ностальгирующих по СССР зарплаты были по 1000р в месяц, так что некоторые категории граждан это могли себе в теории позволить.

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

E>Много битовых флагов в одном байте или слове разруливаются другими техниками. А персональные команды работы с одиночными битами — это мрачные отголоски CISC подхода, который слава богу, уже помер.

Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
А вообще очень прошу объяснить, почему это вдруг такие команды стали "мрачными отголосками CISC".
Накойхер (tm) требовать переводить в цепочку "загрузить 1 — сдвинуть — выполнить операцию" то, что элементарно выполняется в пределах одной команды чуть более продвинутым железом?
Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?

E>История уже поставила все точки на i.

Я боюсь, что она поставила немного не те точки, чем вы

E>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.

А покажите. Какой-нибудь код общего назначения типа qsort.

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

B>>про "клише" так и не понял, но хочу кинуть пару камней.
B>>1) то, что кибернетика была лженаукой, уже нельзя вычеркнуть из истории. и это сильный тормозной фактор развития.
M>А в чем тут проявился тормоз в создании ЭВМ или как их называли тогда ЭСМ?
M>Вот сколько не смотрю на историю появления разных там первых МЭСМ и прочих, вижу что МЭСМ начала разрабатываться в 1948-м (!!!) году, не намного-то и позже США и никто разработки такого рода не тормозил ни тогда, ни в 50-х. Как раз в 60-х пошла идея, что нам проще слямзить на Западе, чем своё развивать.

Тормоз был, например, в отсутствии плотного общения с западными коллегами, из-за чего хорошие идеи с трудом пробивались.
Как бы ни был гениален Лебедев, но машина с одним аккумулятором и 15 индексными регистрами это катастрофически перекошенный дизайн. А это ведь великая БЭСМ-6. Код превращался в сплошную загрузку и выгрузку аккумулятора.
Тут приходит S/360 с 16 почти эквивалентными регистрами для всех целей, и сравнение показывает (это был аргумент в дискуссиях за ЕС тех времён), что код на S/360 в ~3 раза короче эквивалента на БЭСМ-6. И это ещё не вспоминая, что последняя была 16-битной в стиле PDP-11 (виртуальная память формата "маленькое окно в большой мир"). Или та же тотальная двоичная иерархия размеров, которая упрощала многие вопросы дизайна чуть более чем полностью.
И это только уровень двоички. А дальше? Тут рассказывали про таблицы перевода, но для них требовались девочки, а не компилятор.

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

BZ>при этом cisc/epic выжили исключительно благодаря грузу совместимости/финансовой мощи ibm&intel. а самостоятельно прлибвшие себе дорогу mips&arm — это только risc. если вспомнить, то alpha и hp pa были закрыты тоже по маркетинговым причинам, обходя на тот момент конкурентов по производительности
Однако в классе серверов до сих пор господствует x86-x64 архитектура. А учитывая любовь к managed коду на серверах, их перевести на другую архитектуру довольно просто. RISC только в мобилах и планшетах сейчас массово юзается. RISC же периодически используют в приставках, но прыгают туда сюда. PS3 на RISC, а PS4 снова x86 совсестима. А приставкам не нужно сохранять совместимость, и тем не менее они периодически выбирают CISC.

Соответственно комбинированный CISC RISC подход и сейчас вполне жизнеспособен, иначе CISC бы явно умирал. Вполне возможно появятся в скором времени массовые процессоры с программируемой системой команд, позволяющие эмулировать любую архитектуру, и вот тогда появится движуха

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

E>Кроме программной части, Z80 был попроще в эксплуатации. В частности ему требовалось одно напряжение питания, а не 3, как в intel8080.

Для окончательного уточнения — 3 напряжения требовались только оригинальному 8080. Потом начали выпускать 8080A, который удовлетворялся одним, и 8085, который был развитием, аналогичным Z80, но чуть менее навороченным в расширениях, и который не выдержал конкуренции с Z80 (хотя ещё долго его тянули в интеловском embedded как неплохой SoC).

E> Также число тактов на команду в Z80 и intel8080 разное, z80 работает побыстрее.

Да, его в этом плане хорошо оптимизировали.

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

BZ>2. у нас одновременно появилось 2 машины с неймановской архитектурой — в москве и киеве, причём независимо разработанных, чуть раньше такая машина появилась в англии, больше нигде в европе их ещё не было. англичане ездили на неймановские ленкции и разрабатывали свою маишу по американсчким ллекалам. я полагаю, что и наши две машины были сделаны по лекциям неймана, благо что они были достаточно массовыми и туда агебты кгб могли проникнуть. иначе тружно объяснить как сразу два коллектива независимо додумались до того чтобы пропустить ошибки, сопутствовавшие разработке ENIAC

Ой, это какие ошибки имеются в виду?

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

E>Даже книжку откапывать не пришлось, вот сравнительная таблица — система команд одинаковая, но расширеная. Дополнительные команды — это все-то манипуляция с дополнительными регистрами и тесты битов.
Ну и всего-то по-мелочи — добавлены индесные регистры, теневой набор РОН, многие команды расширены доп способами адресации, добавлены короткие относительные переходы, команда цикла DJNZ, команды сравнения с автоинкрементом/декрементом. Чего там, раза в три число команд увеличилось, ерунда

Ну и забыл самую вкуснотищу — блоковые команды LDI/LDIR, LDD/LDDR

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

BZ>девочки-ассемблеры

и диваны — трансляторы

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

E>Теневая страница регистров была придумана разработчиками Z80 исключительно для того чтобы не сохранять и стейт регистров при системных вызовах и востанавливать его потом назад. Прикладной програме туда нельзя было, так что это ничего не меняет.

Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры?

А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было

E>>Там есть команды относительного перехода относительно текущего счетчика команд. на +-128 байт, сама команда двухбайтовая. В z80 очень активно используется. Если что, в i8080 ничего такого нет, переход там всегда 3 байта занимает (если не считать команду программного прерывания RST), и одной этой новой команды достаточно чтоб ни черта не работало.
E>В i8080 команды перехода — относительные, относительно PC — нынешний короткий джамп на x86 со знаковым 16 битным смещением, это он и есть.
Абсолютные. По твоей же ссылке:

JMP address JP address C3address PC <- address
--- JR index 18index PC <- PC + index

E>>Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.
E>Ну а можно было и с битовой табличкой патчить адреса — это в принципе до сих пор так и осталось, хотя использовалось в последний раз в DOS.
Таблицы релокации есть и в PE, и используются, если что.
Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.

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

E>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.

То-то на ARM'е всякие Thumb'ы прикручивать стали

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

E>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>1) Z80 и i8080 — это 16 битовые процессоры.
Да шо ви говорите?

2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
Только у RISC всегда команда была одной длины для ускорения обработки, просто некоторые поля могли не использоваться. Плоьность кода была маленькая. Поэтому к нему прикостылили Thumb-режим

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

E>Да вполне простой RISC укладывается в 1 байт. Но разговор был не том. Если взять один и тот же скомпилированый код, то 32 бит версия для x86 будет _существенно_ длинше чем аналогичная версия для ARM32. Вот и экономия памяти.
Это чушь.
RISC типа быстр и экономичен за счет простоты системы команд — команды совсем примитивные, размер команды строго фиксированный; и поэтому плотность кода существенно ниже, чем у x86.

N> которые противоречат насаждаемым либеральным псевдоисторическим клише в данной области.

Так Гайдар убил в 90е или москали в конце 60х? Видно, что автору хочется пнуть и того и тех, но в итоге получается забавный анекдот, не более.

N> Он потребовал документацию у них. Она пришла. Но по какой-то случайности (Берии уже не было и ответственность практически исчезла) везде не хватало по нескольку страниц, и, самое странное, решающих.

А может и не Гайдар с москалями убили, а эти саботажники?

N>Видимо, Вы смотрели что-то очень древнее, или явно оптимизированное под сокращение размера. Если попросить современный компилятор сгенерировать код с обычными уровнями оптимизации (не какие-нибудь -Os для уменьшения размера), входные точки функций и даже точки начала тела цикла будут выровнены на границу 16 байт. Остаток забивается разными nop'ами. Вот, например, тест xorshift'а, компилятор — clang:
В приведенном Вами коде между командами нет никаких выравниваний.

E>>Да вполне простой RISC укладывается в 1 байт. Но разговор был не том. Если взять один и тот же скомпилированый код, то 32 бит версия для x86 будет _существенно_ длинше чем аналогичная версия для ARM32. Вот и экономия памяти.
M>Это чушь.
M>RISC типа быстр и экономичен за счет простоты системы команд — команды совсем примитивные, размер команды строго фиксированный; и поэтому плотность кода существенно ниже, чем у x86.
Это не чуш. Собери код и сравни — я еще никогда не видел чтобы x86 был бы короче по размеру.

BZ>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
BZ>в risc команды фиксированного размера, включающие код команды, номера гегистров, с котолрыми она работает, режимы адртесации и прочее по мелочи. обычно это 32 бита. есть arm thumb, там размер команды 2/4 байта
для справки.

N>Идея CISC не отвергнута именно потому, что её можно проконвертировать

N>Зато только за счёт конструкции системы команд CISC допускает неограниченное развитие, а RISC — нет. Вон через VEX префикс добавили ещё один аргумент командам. Как ты такое сделаешь на RISC?
Гипотетическое неограниченое развитие системы команд никому не нужно.

N>Вот если они подойдут к порогу остановки — тогда начнётся поиск альтернатив. Собственно, он уже ведётся — каждый следующий техпроцесс сложнее вытягивать. Но покажите мне ARM с аналогом AVX2?
В расширениях ARM есть векторные инструкции и уже довольно давно (еще со времен StrongARMа — это 2003 год примерно).

E>>>И для скорости там выравнивание применяют по границу слова (а для 64 бит и двойного слова кажись), что расточительно черти как. Естественно, что при такой битности сейчас RISC рулит, ибо декодирование команд тривиально.
E>>Код x86 не выравнивается ни по каким границам.
N>См. соседнее сообщение.
См. соседнее сообщение — не выравнивается.

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

E>>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>>1) Z80 и i8080 — это 16 битовые процессоры.
M>Да шо ви говорите?
См выше. Я там уже все написал.

M>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
M>Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
Опкоды и мелкие данные (до 4 бит).

N>Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
Например, такую команду ?

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

N>Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?
E>>История уже поставила все точки на i.
N>Я боюсь, что она поставила немного не те точки, чем вы

Я не являюсь историей.

E>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
N>А покажите. Какой-нибудь код общего назначения типа qsort.
Покажу, но позже.

M>То-то на ARM'е всякие Thumb'ы прикручивать стали
Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

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

E>>>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>Да шо ви говорите?
E>См выше. Я там уже все написал.
Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению

M>>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
M>>Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
E>Опкоды и мелкие данные (до 4 бит).

Википедия с тобой не согласна

Количество инструкций[править | править исходный текст]
Нередко слова «сокращённый набор команд» понимаются как минимизация количества инструкций в системе команд. В действительности, инструкций у многих RISC-процессоров больше, чем у CISC-процессоров.[6][7] Некоторые RISC-процессоры вроде транспьютеров фирмы INMOS (англ.) имеют наборы команд не меньше, чем, например, у CISC-процессоров IBM System/370; и наоборот — CISC-процессор DEC PDP-8 имеет только 8 основных и несколько расширенных инструкций.
На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.[8]
Некоторые архитектуры, специально разработанные для минимизации количества инструкций, сильно отличаются от классических RISC-архитектур и получили другие названия: Minimal instruction set computer (MISC), Zero instruction set computer (ZISC), Ultimate RISC (также называемый OISC), Transport triggered architecture (TTA) и т. п.

M>Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры?

А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было

Обработка IRQ подразумевала переключение страницы регистров. Ваш Кэп.

M>Абсолютные. По твоей же ссылке:
См. выше и научись читать уже же наконец.

E>>>Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.
E>>Ну а можно было и с битовой табличкой патчить адреса — это в принципе до сих пор так и осталось, хотя использовалось в последний раз в DOS.
M>Таблицы релокации есть и в PE, и используются, если что.
M>Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.
Т.е не используется благо есть PIC код. И как я уже говорил последний раз это было актуально при MS-DOS и прочих.

E>>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>>Да шо ви говорите?
E>>См выше. Я там уже все написал.
M>Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению

Еще раз, пожалуста прочти сначала несколько постов выше.

M>>>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
M>>>Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
E>>Опкоды и мелкие данные (до 4 бит).
M>Википедия с тобой не согласна
См выше, там есть пример 8 бит RISC.
Все современные RISC архитектуры имеют ограниченое и маленькое число команд.

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

M>>Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры?

А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было

E>Обработка IRQ подразумевала переключение страницы регистров. Ваш Кэп.

А пруф можно? Жаль всю литературу по Z80 выкинул, так бы сам уточнил. Никогда не встречал такой информации; сам активно использовал теневые регистры, никогда не сталкивался с необъяснимой их порчей, как было бы, если бы твое утверждение было верным. Переключение между наборами производится отдельной инструкцией, и все

M>>Абсолютные. По твоей же ссылке:
E>См. выше и научись читать уже же наконец.
Что я не прочел?

E>>>>Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.
E>>>Ну а можно было и с битовой табличкой патчить адреса — это в принципе до сих пор так и осталось, хотя использовалось в последний раз в DOS.
M>>Таблицы релокации есть и в PE, и используются, если что.
M>>Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.
E>Т.е не используется благо есть PIC код. И как я уже говорил последний раз это было актуально при MS-DOS и прочих.

Ты как-то непонятно и незаметно перепрыгнул с Z80 на x86

BZ>16-битные там от силы сложения подерживались. этим в общем-то и определяют 8 или 16-битный процессор
Ну давай ка вспомним что там еще кроме сложения было то ?

PS: Но я уже писал выше, что оговорился — процессор считался 8 битным с 8 разрядной шиной.

M>>>Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры?

А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было

E>>Обработка IRQ подразумевала переключение страницы регистров. Ваш Кэп.

M>А пруф можно? Жаль всю литературу по Z80 выкинул, так бы сам уточнил. Никогда не встречал такой информации; сам активно использовал теневые регистры, никогда не сталкивался с необъяснимой их порчей, как было бы, если бы твое утверждение было верным. Переключение между наборами производится отдельной инструкцией, и все

С пруфом посложнее, но вот например:

ЦП Z80 содержит два альтернативных блока регистров: главный (A-L) и вспомогательный
(A'-L'). С точки зрения программиста оба блока абсолютно равноправны, но в данный момент
можно работать лишь с одним из них. Переключение этих блоков производится командами ЕХХ и
EX AF.AF'. Такая организация удобна тем, что позволяет быстро сохранить содержимое
регистровых блоков при вызове подпрограмм или при возникновении прерывания. Однако
следует помнить: отсутствует средство подтверждения, какой из блоков (главный или
вспомогательный) используется в данный момент.

M>>>Абсолютные. По твоей же ссылке:
E>>См. выше и научись читать уже же наконец.
M>Что я не прочел?
То что ты не прочел.

M>>>Таблицы релокации есть и в PE, и используются, если что.
M>>>Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.
E>>Т.е не используется благо есть PIC код. И как я уже говорил последний раз это было актуально при MS-DOS и прочих.
M>Ты как-то непонятно и незаметно перепрыгнул с Z80 на x86
Не ты ли написал 3мя строками выше про PE формат ? С моей стороны я всего лишь уточнил что сейчас битовая табличка не используется.

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

M>>То-то на ARM'е всякие Thumb'ы прикручивать стали
E>Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

Ну, наследие не такое уж старое. Thumb2 в 2003 гожу сделали. И вполне активно используется, во всяких встраиваемых недомерках:

Thumb -ориентированные ядра и их развитие

Высокая производительность, великолепная плотность кода

Рынок встраиваемого управления обслуживается в настоящее время 8 и 16-разрядными приборами от большого количества поставщиков. Однако, в перспективных применениях с высокими функциональными возможностями, эти приборы часто не обеспечивают требуемой производительности. Вот почему для таких применений необходима 32-разрядная производительность процессоров RISC, объединенная с высокой плотностью кода, характерной для 16-разрядных процессоров CISC. Технология Thumb обеспечивает обе эти потребности, наводя мосты между 16-разрядными системами и завтрашними 32-разрядными системами.

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

E>>>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>>>Да шо ви говорите?
E>>>См выше. Я там уже все написал.
M>>Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению

E>Еще раз, пожалуста прочти сначала несколько постов выше.

Я всю ветку прочитал, ты можешь конкретно сказать, к какому посту ты меня отсылаешь?

E>См выше, там есть пример 8 бит RISC.
E>Все современные RISC архитектуры имеют ограниченое и маленькое число команд.

Ты об этом что ли — Natalius 8 bit RISC?

Ну, процитирую вики еще раз, если ты не прочитал

Нередко слова «сокращённый набор команд» понимаются как минимизация количества инструкций в системе команд. В действительности, инструкций у многих RISC-процессоров больше, чем у CISC-процессоров.[6][7] Некоторые RISC-процессоры вроде транспьютеров фирмы INMOS (англ.) имеют наборы команд не меньше, чем, например, у CISC-процессоров IBM System/370; и наоборот — CISC-процессор DEC PDP-8 имеет только 8 основных и несколько расширенных инструкций.
На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.[8]
Некоторые архитектуры, специально разработанные для минимизации количества инструкций, сильно отличаются от классических RISC-архитектур и получили другие названия: Minimal instruction set computer (MISC), Zero instruction set computer (ZISC), Ultimate RISC (также называемый OISC), Transport triggered architecture (TTA) и т. п.

M>>>То-то на ARM'е всякие Thumb'ы прикручивать стали
E>>Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

M>Ну, наследие не такое уж старое. Thumb2 в 2003 гожу сделали. И вполне активно используется, во всяких встраиваемых недомерках:
Нет, не пользуются. а) геморно б) нет смысла. Шлепают какую нибудь простенькую микруху аля stm и не парятся.

M>

M>Thumb -ориентированные ядра и их развитие
M>Высокая производительность, великолепная плотность кода
M>Рынок встраиваемого управления обслуживается в настоящее время 8 и 16-разрядными приборами от большого количества поставщиков. Однако, в перспективных применениях с высокими функциональными возможностями, эти приборы часто не обеспечивают требуемой производительности. Вот почему для таких применений необходима 32-разрядная производительность процессоров RISC, объединенная с высокой плотностью кода, характерной для 16-разрядных процессоров CISC. Технология Thumb обеспечивает обе эти потребности, наводя мосты между 16-разрядными системами и завтрашними 32-разрядными системами.

А цитата уже давно устарела, еще из прошлого века похоже.

E>>>>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>>>>Да шо ви говорите?
E>>>>См выше. Я там уже все написал.
M>>>Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению

E>>Еще раз, пожалуста прочти сначала несколько постов выше.
M>Я всю ветку прочитал, ты можешь конкретно сказать, к какому посту ты меня отсылаешь?
Ровно к следующему, после того что ты процитировал.

E>>См выше, там есть пример 8 бит RISC.
E>>Все современные RISC архитектуры имеют ограниченое и маленькое число команд.
M>Ты об этом что ли — Natalius 8 bit RISC?
Это про 8 бит.

M>Ну, процитирую вики еще раз, если ты не прочитал
M>

Нередко слова «сокращённый набор команд» понимаются как минимизация количества инструкций в системе команд. В действительности, инструкций у многих RISC-процессоров больше, чем у CISC-процессоров.[6][7] Некоторые RISC-процессоры вроде транспьютеров фирмы INMOS (англ.) имеют наборы команд не меньше, чем, например, у CISC-процессоров IBM System/370; и наоборот — CISC-процессор DEC PDP-8 имеет только 8 основных и несколько расширенных инструкций.
M>На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.[8]
M>Некоторые архитектуры, специально разработанные для минимизации количества инструкций, сильно отличаются от классических RISC-архитектур и получили другие названия: Minimal instruction set computer (MISC), Zero instruction set computer (ZISC), Ultimate RISC (также называемый OISC), Transport triggered architecture (TTA) и т. п.

Еще раз тогда отвечу: Во всех RISC сейчас число инструкций гораздо меньше чем в CISC. Слово Reduced следует понимать буквально и в плане количества команд.

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

M>>А пруф можно? Жаль всю литературу по Z80 выкинул, так бы сам уточнил. Никогда не встречал такой информации; сам активно использовал теневые регистры, никогда не сталкивался с необъяснимой их порчей, как было бы, если бы твое утверждение было верным. Переключение между наборами производится отдельной инструкцией, и все

E>С пруфом посложнее, но вот например:

	Скрытый текст
	E> ЦП Z80 содержит два альтернативных блока регистров: главный (A-L) и вспомогательный E>(A'-L'). С точки зрения программиста оба блока абсолютно равноправны, но в данный момент E>можно работать лишь с одним из них. Переключение этих блоков производится командами ЕХХ и E>EX AF.AF'. Такая организация удобна тем, что позволяет быстро сохранить содержимое E>регистровых блоков при вызове подпрограмм или при возникновении прерывания. Однако E>следует помнить: отсутствует средство подтверждения, какой из блоков (главный или E>вспомогательный) используется в данный момент.

Ну да, все так. Позволяет — хочешь — сохраняй, не хочешь — не сохраняй. Аппаратных ограничений никаких нет. Сам так и делал — при вызове подпрограммы переключаешься на альт регистры, и с ними работаешь. Гораздо быстрее, чем сохранять на стеке. Единственно, нужно было помнить, какие подпрограммы их используют, вот и все. ПЗУ, насколько я помню, вроде их не портило.

M>>>>Абсолютные. По твоей же ссылке:
E>>>См. выше и научись читать уже же наконец.
M>>Что я не прочел?
E>То что ты не прочел.
Можно все же конкретно привести, что я упустил?

E>Не ты ли написал 3мя строками выше про PE формат ? С моей стороны я всего лишь уточнил что сейчас битовая табличка не используется.

Ну ты про ДОС заикнулся, это уже x86 в любом случае. Если я конечно правильно понял, и имелся в виду MS-DOS, а не TR-DOS

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

M>>>>То-то на ARM'е всякие Thumb'ы прикручивать стали
E>>>Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

M>>Ну, наследие не такое уж старое. Thumb2 в 2003 гожу сделали. И вполне активно используется, во всяких встраиваемых недомерках:
E>Нет, не пользуются. а) геморно б) нет смысла. Шлепают какую нибудь простенькую микруху аля stm и не парятся.

Ок, сейчас не используется. Но ты же не будешь отрицать, что thumb затеяли, чтобы увеличить плотность кода, которая была хуже, чем у x86?

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

E>Еще раз тогда отвечу: Во всех RISC сейчас число инструкций гораздо меньше чем в CISC. Слово Reduced следует понимать буквально и в плане количества команд.

Ок. Допустим. Что тогда ты подразумеваешь под инструкцией в RISC?
Насколько я помню, у RISCа как-то так каждая команда кодируется (по крайней мере, у АРМа):
[Флаги условий][КОП][Ист1][Ист2][Рез-т][Еще какая-то фингя 1][Еще какая-то фингя 2]...
И все это имеет фиксированный размер — т.е. нет никакой переменной длины команд. Что из этого влезает в 8 бит?
И частенько эти команды содержат неиспользуемые поля, которые в CISC x86 убрали бы, укоротив инструкцию, за счет чего в x86 плотность кода была выше.

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

N>>Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
E>Например, такую команду ?

Я же сказал — and, or. Также eor, bic. Вообще-то и арифметика тоже годится. Константа формируется из базового значения и сдвига для образования финальной константы.

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

Такие утверждения требуют доказательства. Особенно когда видно противоположное.

N>>Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?
E>>>История уже поставила все точки на i.
N>>Я боюсь, что она поставила немного не те точки, чем вы

E>Я не являюсь историей.

Метко подмечено. Ну а если попробовать всё-таки распарсить моё предложение?

E>>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
N>>А покажите. Какой-нибудь код общего назначения типа qsort.
E>Покажу, но позже.

Ну, ждём. А пока что не вижу смысла верить на слово.

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

N>>Идея CISC не отвергнута именно потому, что её можно проконвертировать

N>>Зато только за счёт конструкции системы команд CISC допускает неограниченное развитие, а RISC — нет. Вон через VEX префикс добавили ещё один аргумент командам. Как ты такое сделаешь на RISC?
E>Гипотетическое неограниченое развитие системы команд никому не нужно.

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

N>>Вот если они подойдут к порогу остановки — тогда начнётся поиск альтернатив. Собственно, он уже ведётся — каждый следующий техпроцесс сложнее вытягивать. Но покажите мне ARM с аналогом AVX2?
E>В расширениях ARM есть векторные инструкции и уже довольно давно (еще со времен StrongARMа — это 2003 год примерно).

Я просил аналог именно AVX2 (ну ладно, можно и просто AVX), а не вообще "векторные инструкции", реализуемые, BTW, как обращение к сопроцессору (что резко смягчает требования к умещению в прокрустово ложе стандартного конвейера). И как они влезут в существующее пространство команд? Заведёте ещё один номер сопроцессора?

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

Полтакта на команду — Вы эту демагогию оставьте младшей группе ясель, а мы вроде тут взрослые люди. Речь не про суммарный throughput в пересчёте на команду, а про длительность отработки каждой команды от посылки запроса на чтение из памяти до финальной фиксации результатов.
И про мало команд — не надо смешить. Фактически с точки зрения CISC каждая из ARM'овских вариаций — условие выполнения, менять/нет CC, значение сдвига для op2 есть или нет — создаёт новую ось пространства команд. В результате там, где в CISC, грубо говоря, 100 команд, в RISC типа ARM их получается несколько тысяч.

N>>>Идея CISC не отвергнута именно потому, что её можно проконвертировать

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

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

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

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

M>Ок. Допустим. Что тогда ты подразумеваешь под инструкцией в RISC?
M>Насколько я помню, у RISCа как-то так каждая команда кодируется (по крайней мере, у АРМа):
M>[Флаги условий][КОП][Ист1][Ист2][Рез-т][Еще какая-то фингя 1][Еще какая-то фингя 2]...
M>И все это имеет фиксированный размер — т.е. нет никакой переменной длины команд. Что из этого влезает в 8 бит?
M>И частенько эти команды содержат неиспользуемые поля, которые в CISC x86 убрали бы, укоротив инструкцию, за счет чего в x86 плотность кода была выше.
Будь добр, прежде чем задавать глупые вопросы, ознакомся с приведенным выше примером 8 битного RISC. Там есть и опкоды и как это работает.

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

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

N>>>Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?
E>>>>История уже поставила все точки на i.
N>>>Я боюсь, что она поставила немного не те точки, чем вы

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

E>>>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
N>>>А покажите. Какой-нибудь код общего назначения типа qsort.
E>>Покажу, но позже.
N>Ну, ждём. А пока что не вижу смысла верить на слово.
Не хотите — не верте — я вас не заставляю.

M>Ок, сейчас не используется. Но ты же не будешь отрицать, что thumb затеяли, чтобы увеличить плотность кода, которая была хуже, чем у x86?
Плотность кода у ARM лучше чем у x86.

M>Ну да, все так. Позволяет — хочешь — сохраняй, не хочешь — не сохраняй. Аппаратных ограничений никаких нет. Сам так и делал — при вызове подпрограммы переключаешься на альт регистры, и с ними работаешь. Гораздо быстрее, чем сохранять на стеке. Единственно, нужно было помнить, какие подпрограммы их используют, вот и все. ПЗУ, насколько я помню, вроде их не портило.
Ну вот не уверен. Разработчики Z80 эту фичу как раз для системных нужд сделали.

M>>>>>Абсолютные. По твоей же ссылке:
E>>>>См. выше и научись читать уже же наконец.
M>>>Что я не прочел?
E>>То что ты не прочел.
M>Можно все же конкретно привести, что я упустил?
Поробуй все же прочесть ветку еще раз.

E>>Не ты ли написал 3мя строками выше про PE формат ? С моей стороны я всего лишь уточнил что сейчас битовая табличка не используется.
M>Ну ты про ДОС заикнулся, это уже x86 в любом случае. Если я конечно правильно понял, и имелся в виду MS-DOS, а не TR-DOS

DOSов много было, буквально — Disk Operating System. CP/M — тоже DOS. Но во всех вариантах битовая табличка релокации после DOS-ов не используется.

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

M>>Ок, сейчас не используется. Но ты же не будешь отрицать, что thumb затеяли, чтобы увеличить плотность кода, которая была хуже, чем у x86?
E>Плотность кода у ARM лучше чем у x86.

Убедил

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

M>>Ну да, все так. Позволяет — хочешь — сохраняй, не хочешь — не сохраняй. Аппаратных ограничений никаких нет. Сам так и делал — при вызове подпрограммы переключаешься на альт регистры, и с ними работаешь. Гораздо быстрее, чем сохранять на стеке. Единственно, нужно было помнить, какие подпрограммы их используют, вот и все. ПЗУ, насколько я помню, вроде их не портило.
E>Ну вот не уверен. Разработчики Z80 эту фичу как раз для системных нужд сделали.

Еще раз говорю, что вообщем-то не важно, что там задумывали разработчики. Важно то, как оно работало. И я не не уверен, я знаю, как это работало. Я много писал тогда на асме для спектрума.

E>>>Не ты ли написал 3мя строками выше про PE формат ? С моей стороны я всего лишь уточнил что сейчас битовая табличка не используется.
M>>Ну ты про ДОС заикнулся, это уже x86 в любом случае. Если я конечно правильно понял, и имелся в виду MS-DOS, а не TR-DOS

E>DOSов много было, буквально — Disk Operating System. CP/M — тоже DOS. Но во всех вариантах битовая табличка релокации после DOS-ов не используется.

Ну, если не указывать точное название, обычно подразумевается MS-DOS, как наиболее распространенная DOS

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

E>Так это Гайдар оказывается является причиной того, что до 90-х даже спектрум был мечтой? А то ведь массово спектрум совместимые в промышленных масштабах по приемлемой цене появились именно в 90-е, если что.

Спектрум-совместимые в промышленных масштабах по приемлемой цене появились ещё с середины 80-х.
Отец мне купил "Спектрум" Ленинградской сборки летом 88-го. К тому моменту Спектрумами обзавелись уже несколько знакомых, в городском парке в зале игровых автоматов стояло пяток Спектрумов, на которых за небольшую денюшку давали поиграть, а в магазинах электроники были витрины с пиратскими копиями спектрумовских игрушек.

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

вот тут люди, создавшие демос и релком, очень интересно описывают как все было в ссср и что такое перестройка. очень интресное чтиво.

вся правда о демосе: http://news.demos.su/private/demos.html

...

Началось все примерно в 1983 году. "Наши" люди сподобились вытащить Unix v7 прямо с VAXа Калифорнийского университета в Беркли (Сан Диего). (Не-а, в Беркли, что напротив Сан-Франциско; хорошее место, траву прям на улице курят. Что и объясняет особенности берклеского юникса. (Антонов-ст.))

...

Собственно, началось все чуть раньше. Сначала наше общество разделилось на ЕС-о ненавистников (занимавшихся БЭСМ-6) и ЕС-о любителей. После и там и там начало появляться понимание того, что сидим мы на, извиняюсь, старье и дерьме (неважно, аппаратном или программном — и там и там операционные системы явно отставали от жизни), и что надо куда-то двигаться. И тут появилась идея машинно-независимой ОС Unux. В ИАЭ им. Курчатова за нее ухватились Бардин и Паремский, на ВМК — я уже не помню, кто именно (зато я помню — Маслов А.Н., каковой и был моим ученым руководителем в оном ВМК. (Антонов-ст.)), но именно она послужила объединяющим стимулом для нескольких разных групп программистов — одни любили много лампочек, прерывания, ленты и мониторную систему Дубна, другие — великую и могучую ОС/ЕС (любили странною любовью), третьи подвизались с не менее занимательными ОС RT-11 и RSX. И все хотели чего-то стабильного и не зависящего от левой ноги очередного производителя железа. (Руднев)

...

Так дальше жить было нельзя. Все это понимали и молча "локализовывали" все, что приходило из Африки (это не шутка — все программы, украденные в США, по какой-то причине имели африканский след на лентах ... — ну не все, не все, были и из Вены, были и прямо из Беркли (Егошин)). Были и такие, как, например, Бутенко и Флеров (МИСС, физфак МГУ), которые без страха и упрека стали разрабатывать свои ОСы..., а на мехмате разрабатывался Микромир (Кушнеренко) — Windows рядом не валялся...

. Были и счастливчики. На русское золото покупались суперкомпьютеры, например, на АЗЛК в это время появились Макинтоши с их невообразимым интерфейсом и украденными позже Биллом Г. окнами...

...

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

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

Когда начинаются такие отговорки, это обычно признак того, что аргументы заканчиваются.

E> Intel делает то что хочет — это его право.

Кто бы спорил, я не буду.

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

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

Если она аналогична, тогда для Вашего рассмотрения MMX и SSE — это одно и то же, а какой-нибудь FMA вообще левая незначительная деталь.

E> Векторная арифметика логически реализуется одельным сопроцессором, в ARM их может быть до 16 штук. Физически это может быть тот же самый кристал с тем же 0.5 такта на команду.

Вы цитируете основы документации вместо конструктивного ответа. Повторю вопрос. Когда кончатся коды команд, Вы аллоцируете новый номер сопроцессора?

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

"Нечем аргументировать" это про Вас.

E> Сумарное время зависит от конкретного железа, наличия и отсутсвия кешей и много другого, точно также как и дляч платформы x86.

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

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

Именно! Каждая отдельная команда — одна. Но всего таких команд может быть, если подсчитать по методам, как считают команды для CISC, тысячи.
Вы вообще читаете, на что отвечаете, или решили просто отмахнуться, увидев знакомые слова?

E> При CISC подходе для этого требуется 100500 различных команд — различные проверки статусных битов, команды условного перехода и многое другое.

Это не "CISC подход", учитывая, что условное выполнение команд по методу ARM32 убрали даже в его ближайшем родственнике AArch64, и его не было в Thumb. Фактически, мало в каком RISC это было. Вы и тут не разбираетесь в теме, однако.

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

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

eor %r1, #0x100000

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

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

Я уже привёл трижды. Вы не знаете устройство ARM или не хотите читать?

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

Вы таки пытаетесь что-то рассказывать об области, в которой абсолютно невежественны и столь же абсолютно упорны.

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

D>Это не так, просто, если придется работать -- у ГПУ 4-8 железных камней, которые умеют делать симд 16-64 элементов. Также он довольно шустро метается с нитки на нитку, если нитка занимается чем то жолгим, например чтением из памяти, что и дает довольно выское количество параллельных процессов.
Хм... Информация интересная. В принципе, если внутри это просто SIMD, то понятно тогда почему нельзя разные ветвления в разных тредах делать без потерь производительности. А с высокого уровня все выглядит именно как куча процессоров, неслабо смогли скрыть сложность.

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

AK>Спектрум-совместимые в промышленных масштабах по приемлемой цене появились ещё с середины 80-х.
С середины 80-х в достаточных масштабах они в буржундии только появились. В 82, когда он был выпущен, его было крайне проблематично купить даже в Великобритании.
В СССР же проблемно было купить даже БК. Спектрум клоны же начали появляться не в середине, а в конце 80-х. "Ленинград" — это 1989 год. А то и 91-й, в зависимости от модификации. "Львов" в теории можно было купить и раньше.

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

А именно в СССР из вычислительной техники были массовыми программируемые калькуляторы, а не компьютеры. Расцвет всего был — 1985 — 1988й год. Только в 1990-м году, например, в технике молодежи в "клубе электронных игр" начали появляться уже тематики на компьютерную тему, а калькуляторы уже стали менее актуальны. Содержание журналов — довольно неплохое доказательство степени компьютеризации в стране. Я начинал именно с калькулятора, а о компе только мечтал.

Здравствуйте, мыщъх,

уууу! Впервые ты писал об этом году еще этак в 1998-99, нет?

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

Y>

Y>Буржуазная печать широко разрекламировала новую науку — кибернетику. Эта модная лжетеория, выдвинутая группой американских «учёных», претендует на решение всех стержневых научных проблем и на спасение человечества от всех социальных бедствий. Кибернетическое поветрие пошло по разнообразным отраслям знания: физиологии, психологии, социологии, психиатрии, лингвистике и др. По утверждению кибернетиков, поводом к созданию их лженауки послужило сходство между мозгом человека и современными сложными машинами.

Y>— Ярошевский М. «Кибернетика — «наука» мракобесов», «Литературная газета», 1952, 5 апреля. № 42(2915), стр.4

Во, это вообще ясно видно, что точно не против "современных сложных машин" было направлено.

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

M>Я в реале не имел дела с БЭСМ или ЕС, поэтому не имею личных впечатлений. Тем не менее, от чтения разных мемуаров сложилось такое, что разным физикам и инженером намного лучше было работать с БЭСМ-6, чем с ЕС. ЕС еще и намного чаще ломалась.

Я был знаком с парой инженеров, работавших в то время на IBM. Они говорили, что, в отличие от ЕС, она не ломалась. Главное — регламент соблюдать. Профилактики вовремя, температура...

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

M>У меня такое ощущение, что когда ее называли лженаукой это имело более философский смысл и направлено было против идеи распространить математические методы кибернетики на человеческое общество...

Я об этом читал. Давно, правда. Источники найти не удалось.

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

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

A>>Да, это Гайдар придумал. Вот в этом ты весь. Вопиющая безграмотность.

Y>Не Гайдар, а Черчиль. В восемнадцатом году. Может хватит прозориться?

Ну не знаю, что ты позоришься.

Y>http://fotoru.info/wp-content/uploads/2011/04/fil1.jpg
Y>[url]http://fotoru.info/wp-content/uploads/2011/04/fil21.jpg

A>>Ты бы хоть Википедидию почитал.

Y>Ваща Википедия заботливо сообщает:

Y>

Y>Буржуазная печать широко разрекламировала новую науку — кибернетику. Эта модная лжетеория...
Y>— Ярошевский М. «Кибернетика — «наука» мракобесов», «Литературная газета», 1952, 5 апреля. № 42(2915), стр.4

Ну ты-то сам как считаешь, тянет ли статейка в «Литературной газете» супротив двух изданий Винера?
А супротив Института точной механики и вычислительной техники?

А если подвинуть глаза на 1 сантиметр и следующий абзац в этой же самой статье Вики прочесть?

Тем не менее, вычислительная техника в СССР стремительно развивалась. В 1950 году заработала МЭСМ (Малая электронная счётная машина) — первая в СССР ЭВМ, разработанная лабораторией С. А. Лебедева на базе киевского Института электротехники АН УССР, а в 1952 году — БЭСМ-1. В 1950—1951 годах была разработана ЭВМ М-1 в Лаборатории электросистем Энергетического института АН СССР под руководством члена-корреспондента АН СССР И. С. Брука. В 1953 году началось серийное производство ЭВМ Стрела, разработанной в СКБ-245 Ю. Я. Базилевским.

Этот приём демагогии, который ты безуспешно пытаешься применить,
называется "сделать из мухи слона".
Но применил ты его плохо, по детсадовски.
Потому и не сработало.

И это я еще не сказал, что ты не знаешь, какая "кибернетика" имелась в виду.

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

Q>Значит меня сбили с толку мнемоники — они другие, поэтому я думал что и система команд другая.

Мнемоники пришлось поставить другие из-за претензий Intel (напомню, Z80 делали выходцы из Intel)

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

N>Непейвода Н Н:

N>

N>Несколько раз мне приходилось читать курс истории информатики. Я хочу поделиться некоторыми фактами, которые противоречат насаждаемым либеральным псевдоисторическим клише в данной области. Кажется, часть из них в печати не встречалась. Конечно, те, кто не хотят знать ничего, потребуют письменных подтверждений. Но я учился у пионеров и работал вместе с классиками. Многое тогда они записывать не могли. Приводить буду лишь то, что мог перепроверить по крайне мере двум относительно независимым источникам, один из которых — непосредственный участник событий.

Вот как-то мне господин Н.Н. кого-то напоминает. То ли он "айтишный чубайс", то ли "айтишный навальный"...

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

AK>>Спектрум-совместимые в промышленных масштабах по приемлемой цене появились ещё с середины 80-х.
E>С середины 80-х в достаточных масштабах они в буржундии только появились. В 82, когда он был выпущен, его было крайне проблематично купить даже в Великобритании.
E>В СССР же проблемно было купить даже БК. Спектрум клоны же начали появляться не в середине, а в конце 80-х. "Ленинград" — это 1989 год. А то и 91-й, в зависимости от модификации. "Львов" в теории можно было купить и раньше.

у меня досихпор лежит схема "краснодара" датированная 86 годом тогда же предлагали комплект плата/схема + z80, но не осилили по деньгам, копию схемы мне сделали бесплатно
elmal в целом вы правы но ленинград в массовом количестве стал появляться еще в 1988, посмотрите дату на плате http://sblive.narod.ru/ZX-Spectrum/Leningrad48k/LenPCBPhotoTop.jpg

в 90ом уже активно шли Пентагоны и начались Поиски на 88

Здравствуйте, 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 стоила тысячи рублей так что на домашний комп никак не тянула
Да, это совсем не домашний комьютер.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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>Лично я говорю об области которой посвятил не один год и не два.

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

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 его отменили) условное выполнение? я его как-то не отрицал.

Здравствуйте, 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 кэша), декодируется и хотя бы начнёт исполняться?

	От:	elmal
	Дата:	09.06.14 09:48
	Оценка:	+4

	От:	elmal
	Дата:	09.06.14 08:14
	Оценка:	+3

	От:	Yoriсk
	Дата:	10.06.14 09:51
	Оценка:	28 (2)

	От:	alpha21264
	Дата:	09.06.14 07:47
	Оценка:	-1

	От:	eskimo82
	Дата:	09.06.14 08:11
	Оценка:	-2

От:	denisko	http://sdeniskos.blogspot.com/
Дата:	09.06.14 17:51
Оценка:	7 (1)

От:	bastrakov	http://bastrakof.livejournal.com/
Дата:	09.06.14 06:52
Оценка:	+1

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	10.06.14 08:06
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	10.06.14 13:15
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	17.06.14 11:00
Оценка:	+1

От:	Pzz	https://github.com/alexpevzner
Дата:	09.06.14 10:50
Оценка:

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	11.06.14 03:06
Оценка:

От:	мыщъх	http://nezumi-lab.org
Дата:	11.06.14 03:11
Оценка: