Каким должен быть НОВЫЙ процессор.
История повторяется.
Я даже не буду уточнять как она повторяется.
Я даже не буду повторять, что история учит тому, что она многих ничему не учит.
Иногда я не тороплюсь читать о перспективных разработках.
Даже о разработках известных мировых фирм, которых сам достоверно не выверял.
Не выверял своими многократными исследованиями на практике программирования.
Я делаю так, чтобы зазомбированно не следовать по скороспелым ложным путям.
Сейчас я точно знаю, каким должен быть процессор моей мечты.
Я бы назвал его - MY DREAM proceccor или просто - МЕЧТА.
По существу дела, концептуально - я назвал этот процессор - Luxium.
Как практик, я конечно же, всегда делаю всё, чтобы мечта - осуществлялась.
В моей истории - первыми были двухадресные процессоры серии Минск.
В них были какие-то недостатки, но никаких излишеств практичеки не было.
Вторыми в моей истории - были трёхадресные процессоры серий БЭСМ4 - М222.
Три адреса в команде часто были излишеством, даже в двуместной арифметике.
И в двуместной логике тоже - маркотно было выписывать все три операнда.
Был ведь регистр результата операции - куда тот записывался и по умолчанию.
Этот результат годился и вместо первого операнда следующей операции.
Так, что - всегда был необходимо нужен - только второй операнд.
В командах перехода - также, точно необходим был - только адрес перехода.
Другие адреса оставались ДЫРАМИ в команде, поскольку они не использовались.
Конечно, можно было заткнуть ДЫРУ - ПРИСОБАЧИВ, к переходу - пересылку.
Это оптимизация вида - сначала СОЗДАЮТ проблему, а потом её - ПРЕОДОЛЕВАЮТ.
Оптимально - в команде должно быть только столько адресов - сколько необходимо.
Практически так оптимально и было в ряду моделей IBM-360 - IBM-370 - IBM S-390.
Практически так же оптимально было и в ряду моделей DEC PDP-11 - DEC VAX-11.
И в команде процессора Intel 80x86 - практически, так - оптимально и было.
Но разработчики процессоров, решили вновь перетянуть одеяло - на себя.
Они вновь вытащили сомнительную концепцию ДЫРЯВОГО трёхадресного процессора.
Дескать - каждый операнд операции RISC должен жёстко занимать свою позицию.
Это - вроде бы - упрощало декодирование сразу всей RISC команды - целиком.
Хотя время декодирования команды не так уж соизмеримо с временем её выполнения.
Вопрос и в том - так уж ли отличаются времена декодирования команд RISC и CISC.
А проблему ДЫРЯВОСТИ команд вновь спихнули на разработчиков компиляторов.
Вряд ли компиляторщики смогли заткнуть - все ДЫРЫ исполняемого кода команд.
Но вопреки концепции RISC - рынок наводнили Intel 80x86 и их клоны AMD.
Ведь фирма Интел де факто в течение двух десятилетий отрицала концепцию RISC.
Отрицала, вместе c её крайне жёстко-конвейрно-орентированной системой команд.
Например, такой, которую эти два десятилетия использовала IBM - в Power PC.
Интел упорно продолжала развивать свою прежнюю концепцию - Intel 80x86.
И это не помешало Интел использовать двух-конвейерную схему - в Pentium.
И именно - Pentium стал несравненно более массовой моделью, чем Power PC.
Причём, реально - Pentium особенно и не уступал Power PC в быстродействии.
Процессоры Xeon - линии Intel 80x86 - используются даже в суперкомпьютерах.
Поэтому - выходит, что RISC системы, в быстродействии, не имеют особого смысла.
Может быть система Intel Itanium и не относится к традиционным RISC системам.
Но Itanium использует такую же - трёхадресную команду, как и RISC Power PC.
Или такую же - 3х-адресную команду как широко используемые в гаджетех RISC ARM.
Более того - команда Itanium - даже не байтоориентирована по своей структуре.
Более того - команда Itanium - имеет и четырёхоперандные адресные модификции.
Это также - в силу ДЫРЯВОСТИ жёстко-конвейрно-орентированной системы команд.
При наличии ДЫРЯВОСТИ есть соблазн заткнуть ДЫРУ - ПРИСОБАЧИВ ещё чего-либо.
Это оптимизация вида - сначала СОЗДАЮТ проблему, а потом её - ПРЕОДОЛЕВАЮТ.
Но вряд ли - в командах Itanium удастся заткнуть большое множество ДЫР.
Цетная палитра матрицы системы команд Itanium содержит очень много белых ДЫР.
А проблему ДЫРЯВОСТИ команд вновь спихнули на разработчиков компиляторов.
Вряд ли компиляторщики смогут заткнуть - все ДЫРЫ исполняемого кода команд.
Но в то же время - просессор Itanium поддерживает и архитектуру команд IA-32.
Вопрос в том - что здесь конептуально есть временное, а что - постоянно.
А что, если сравнить на одних и тех же задачах сам Itanium и его же IA-32.
Одни и те же программы, транслированные с C++ в код Itanium и его же IA-32.
Сравнить это по объёму исполняемого кода и времени выполнения программ ...
Вот тогда и можно было бы делать практические выводы ...
А пока мне импонирует ясная байтоориентированная система команд!
И я знаю - какой она должна быть!
Выше я изложил краткие логические посылки-тезисы-аргументы данной проблемы.
Далее - рассмотрим эту проблему несколько подробнее.
Ведь команды-инструкции системы-набора команд-инструкций служат в конечном итоге элементами для создания выражений.
Прикладной итерфейс должен быть больше системой, чем просто набром команд ...
Само выражение уже предопределяет последовательность связи термов выражения которые через промежуточнные результаты вычисляют конечный результат выражения.
Поэтому - операнды, которые каждй раз занудно показывают и напоминают - откуда брать первый операнд двуместной операции и куда помещать результат - как правило - совершенно не нужны.
Это ярко видно на примере простейшего линейного арифметического выражения вида:
alpha * beta / gamma + delta - eta
Это выражение на языке ассемблера трёхадресной машины выглядит так:
mul accum,alpha,beta
div accum,accum,gamma
add accum,accum,delta
sub accum,accum,eta
Или в так называемых - наглядных содержательных обозначениях(showable signes):
=*:A,alpha,beta =/:A,A,gamma =+:A,A,delta =-:A,A,eta
Как мы можем здесь видеть целых 7 адресов - accum - из 12, т.е. БОЛЬШЕ ПОЛОВИНЫ (!!!) адресов - здесь(!) совершенно не являются столь необходимыми.
Именно ЭТИ адреса, которые совершенно не являются столь необходимыми я и называю - ДЫРАМИ.
А в процессоре Itanium - фирмы Intel - к тому же - имеются в наборе команд (и в изрядном количестве) ещё и СУПЕРДЫРЫ - которые ВООБЩЕ НИКОГДА НЕ ИСПОЛЬЗУЮТСЯ.
Это же выражение на языке ассемблера двухадресной машины выглядит так:
mov accum,alpha
mul accum,beta
div accum,gamma
add accum,delta
sub accum,eta
Или в так называемых - наглядных содержательных обозначениях(showable signes):
:=A,alpha :*A,beta :/A,gamma :+A,delta :-A,eta
Как мы можем здесь видеть целых 5 адресов - accum - из 10, т.е. РОВНО ПОЛОВИНА (!!) адресов - здесь(!) совершенно не являются столь необходимыми.
Это же выражение на языке ассемблера одноадресной машины выглядит так:
mov alpha
mul beta
div gamma
add delta
sub eta
Или в так называемых - наглядных содержательных обозначениях(showable signes):
=:alpha *beta /gamma +delta -eta
Как мы можем здесь видеть ровно 0 адесов (accum) из 5, т.е. РОВНО НОЛЬ (!!) адресов - здесь(!) совершенно не являются столь необходимыми, поэтому их здесь и НЕТ !!!
Это же выражение на языке ассемблера машины Intel-80586 выглядит так:
mov eax,alpha
mul beta
div gamma
add eax,delta
sub eax,eta
Или в так называемых - наглядных содержательных обозначениях(showable signes):
:=A,alpha *beta /gamma :+A,delta :-A,eta
Как мы можем здесь видеть целых 3 адреса - eax - из 8, т.е. БОЛЬШЕ ТРЕТИ (!!) адресов - здесь(!) совершенно не являются столь необходимыми.
Именно ЭТИ адреса, которые совершенно не являются столь необходимыми я и называю - ДЫРАМИ.
А в процессоре Itanium - той же фирмы Intel - к тому же - имеются в наборе команд (и в изрядном количестве) ещё и СУПЕРДЫРЫ - которые ВООБЩЕ НИКОГДА НЕ ИСПОЛЬЗУЮТСЯ.
Мне могут возразить, что я выбрал для примера слишком простое выражение.
Но я знаю - как линеаризовать сколь угодно сложные выражения.
Это же выражение на языке Люкс для трёхадресной машины может выглядеть так:
accum:=alpha*beta accum:=accum/gamma accum:=accum+delta accum:=accum-eta
Это же выражение на языке Люкс для двухадресной машины может выглядеть так:
accum:=alpha accum*beta accum/gamma accum+delta accum-eta
Это же выражение на языке Люкс для одноадресной машины может выглядеть так:
=:alpha *beta /gamma +delta -eta
Это же выражение на языке Люкс для машины Intel-80586 выглядит так:
alpha *beta /gamma +delta -eta
То есть РОВНО ТАК ЖЕ - КАК И НА ЯЗЫКЕ ВЫСОКОГО УРОВНЯ - тах как Си, Ява, Паскаль и т. п. ...
Получается яное противоречие - нонсенс, выражающийся в том, что язык ЭЛЕМЕНТАРНЫХ команд-кирпичиков машинного кода в двух и трёх-адресной арифметике избыточно ВЫШЕ, чем в простом арифметичемком выражении, в том числе и выражении языка ВЫСОКОГО уровня, тах как Си, Ява, Паскаль и т. п. ...
Мне могут возразить, что я веду речь лишь только о компактности кода.
Но сегодня традиционно и широко используется быстродействующая кэш-память кода!
И чем компактнее исполняемый код, тем больше его войдёт в кэш-память кода!
А чем больше коротких циклов войдёт в кэш-память кода, тем быстрее программа!
А короткий побайтовый код вовсе не мешает использовать параллельные конвейеры.
Это доказала сама фирма Intel много лет используя такие конвейеры в Pentum-4.
Короткий побайтовый код понятен, прозрачен и идеально подходит транслятору.
Это значительно повышает быстродействие транслятора кода и компиляции!
Ведь при разработке-отладке программы - её приходится часто транслировать.
И число таких трансляций-пусков программы может доходить до сотен тысяч раз.
В совокупности причин и обстоятельств распараллеливание и конвейеризация короткого байтового кода может оказаться предпочтительнее.
Я обращаюсь к руководителям и ведущим специалистам фирм занимающихся разработкой архитектуры процессоров для различных устройств от коммуникаторов и планшетных компютеров до ноутбуков и настольных компьютеров, и даже - до суперкомпьютеров с предложениями по совместной разработке архитектур современных нанопроцесоров для компьютеров любой величины и сложности.
Мои разработки достаточно продвинуты и детально проработаны до моделирования моих собственных систем команд компьютерных процессоров и эмуляции программ составленных на их основе, на программных эмуляторах-интерпретаторах различных систем команд для компютерных процессоров, подлежащих, в конечном итоге - изготовлению в виде электронных наночипов любой сложности.
Короче говоря, я уже программирую на этих моделях процессоров будущего и отлаживаю эти свои программы на программных эмуляторах-интерпретаторах систем команд этих процессоров будущего.
Мы с Вами прошли ОГРОМНЫЕ пути, и на этих путях оттачивали продуктивным опытом - каждый свои НОУ-ХАУ ...
Но ТОТ ОГРОМНЫЙ и ДЛИННЫЙ АКТИВНЫЙ и ПРОДУКТИВНЫЙ ПУТЬ - который прошёл я, не проходил ЕЩЁ - НИКТО.
И мне сейчас не ВРЕМЯ и не РЕЗОН - уверенно не заявить о себе - от ложной скромности.
ПОРА - ДЕЙСТВОВАТЬ ...
Ещё вчера была пора - ДЕЙСТВОВАТЬ!
***
