Предполагам много от вас са работели с различни професори и са се кефели на предимствата на някой и са се дразнели от простотията в други... Аз самият вече съм "претръпнал" и приемам нещата такива каквито са и работя с един или друг процесор не защото е идеален ами защото трябва да искарам някой лев
Само от време на време, като ме домързи да бачкам почвам да умувам колко по-добре щеше да е ако процеосорите бяха такива или онакива. През годините съм събрал много идеи за "перфектният професор", част от които мои лични, други съм видял някъде - няма значение, проблемът е че повечето от нещата са взаимно изключващи се и не става да се съчетаят автоматично в задание за чип.
Предложението ми е ако има мераклии, да поумуваме заедно - кой когато намери време и да поотсеем малко трици Целта е да се направи концепция за много добър контролер.
Самата имплементация не ме вълнува толкова, даже искам да подчертая че идеята ми не е да се направи "нещо си". Познавам някои ядра, пък и аз самият вече съм правил "подобия" на процесори. Няма нищо по-лесно от това да се направи процесор - проблемът е да се измисли добър такъв, а пък още по-големият проблем който изобщо не е лъжица за нашата уста е да се изкарат пари от цялото упражнение.
Все пак крастата си е краста обаче

И така... къф трябва да бъде перфектният професор?
Няма нужда да казвам че трябва да е лесен за използване, супер производителност, с малко код да върши много работа и т.н и т.н. Ще кажа само че е по-важно да е завършен контролер - да има ясна идея как ще се работи хардуерно с него, периферии ала бала и в същото време софтуерно да е удобен за ОС, многозадачност, синхронизации и прочее.

Ще мина направо към идеите, пак повтарям те може да си противоречат и се надявам на обсъждане което да позволи отсяването на по-полезните...

Идея #1. Инструкции-функции .
Стандартно, процесорите имат инструкции които наподобяват "процедури" с N на брой параметъра. Правят каквото правят, но не връщат резултат. И за да се направят по-сложни изрази се изпълняват поредица инструкции, като за бързина междинните резултати се съхраняват в регистри.
Идеята е, инструкциите да са функции - с 1, 2 или повече параметъра и да връщат резултат, който пък може да служи за параметър на следващата инструкция. За математическите/логическите функции е ясно... допълнително трябва да има функция(оператор) за присвояване, който както в С-то си взема 2 параметъра и връща резултат. Евентуално функция за извличане на константи (1 параметър - отместване от програмния брояч). Функция за извличане от паметта и т.н.
Тук има доста подробности, примерно междинните резултати - то е ясно че има нужда от такива, като идеята е да се ползва автоматичен стек, който ще се кешира в ядрото (знам става малко по-сложничко). Де-факто кеширанта част все едно представлява отделна банка регистри използвана само за междинни резултати. Само дето професорът сам си знае кой от междинните регистри кога да използва.
Къде е разликата?
Значи, стадартно един процеосор има определен брой регистри. Като броят на регистрите е компромис между това да се намалят операциите със стека и това да се нали броят битове за кодиране на инструкциите.
Въвеждането на "функции" позволява да се намали броят на основните регистри, защото те няма да се ползват за ременни резултати, т.е. всичките може да ги запълним с променливи. Същевременно, при сложен израз (съвкупност от операции) може да се намали код-сайза защото не се кодират индексите на междинните регистри - те се определят автоматично.
Пример, имаме израз от типа R0 and R1 + R2 and R3
Стандартно да приемем че се кодира така:
AND R4, r0, r1
AND R5, r2, r3
ADD Rx, R4, r5

което общо взето се кодира с 3*4=12 байта


При нас би се получилo:
r0, r1, and, r2, r3, and, add

което спокойно може да се кодира с 7*1=7 байта

За колко битово животно иде реч 16/32/64?
Хардуеерно умножение,деление,операции върху числа с фиксирана/плаваща запетая?

говоря за концепция само... няма значение на концептуално ниво колко бита е, въпреки че си прав - трябва да има идея за каква архитектура говорим

Проблемът ми е че идеите са повече отколкото трябва... относно архитектурата си мисля за "междинка" демек искаш 32-бит - имаш 32 бит операции. Обаче в определени случаи да може да си работиш и все едно че е 8/16 бит. Трябва да го избистря това как ще стане... Засега мога само да кажа че не ми харесва АРМ концепцията която прави доста овърхед тъй като всичко е 32 бит, пък на практика паметта < 64К. Само хабят указатели

Умножение и деление е добре да има... за плаваща запетая - не знам (може би няма нужда чак пък толкоз)

много не се задълбочих в идеята - но това дето се приближада до твоята "концепция" е стековата органицация на 8087

... писането на asm за 8087 изисква доста внимание от програмиста (ако ще ползва ST(0)...ST(7) ) ... но като идея е доста добра
на практика аргументите са като на функции - резултата остава в стека и може да се ползва от следващата инстр. ...

забравих на-важното:
при преключването на задачи основен проблем е запазването на текущото състояние на регистрите, така че повече регистри -> повече неща за пазене. при стековата -> може да се пазят само тия дето се ползват (според показанието на указателя на стека - регистровия) ... това може да спести доста местене на памет

Да, някои неща се точно като в стековите процесори.
Не, няма да бъде само стеково ориентиран.

По-точно само резултатите от инструкциите ще са със стекова концепция, но иначе стандартните регистри и организация си остават.


идеи за архитектура

Първо, като чип може да има няколко външни шини, които да са нормални адрес/данни или io, fifo, dma или както аз им викам видео. Колко и какви шини ще има зависи от конкретната имплементация. По принцип няма да има ограничения. Отделните шини могат да бъдат на отделни лейари така че по всички едновременно може да се извършва трансфери. За да не използвам тая чуждица Layer ще казвам просто "шина"..
За самото ядро предвиждам до 3 шини. Една за извличане на код и две за данни. Въпреки че от коя да е шина може да се извличат и код и данни, но за максимална производителност е добре да са различни.
Перифериите могат да се конфигурират също на различни шини, така че да има минимални конфликти и да няма бездействащи шини.

И/О портове
Подобно на х86 портовете и тук предвиждам нещо такова, ама не съвсем...
Портовете ще си имат номера и ще се ползват както се ползват регистрите. Примерно ако R1 e регистър 1, I5 съответства на 5-ти порт. Но портовете ще са "виртуални" в смисъл че ще се "програмира" какво точно отговаря на 5-ти порт. Като портове ще могат да се мапват кои да са външни шини, като за шините с адресация порта ще се програмира както се програмира ДМА или кръгов буфер. Кръговите буфери ще могат да се ползват както за междутаскова комуникация, така и за обмен на данни с периферия/драйвери.
Въпреки че портовете за софтуера ще изглеждат по същия начин както регистрите, операциите с портовете могат да имат страничен ефект - ако от другата страна няма готовност, текущия таск ще забие и ще загуби управление. Самото превключване на контекстите може да стане автоматично от хардуера или по-простия начин - ако в порта няма готовност се генерира прекъсване/ексепшън и от там ОС-а поема нещата.

Архитектурата на самото ядро...
Старите процесори бяха с микрокод и опкод, което прилича на компютър в компютъра. Сега новите с pipeline и MDMI/SIMD/.. вместо да правят едно нещо за няколко стъпки (клока) правят няколко неща за един клок...
Аз си мисля за съчетаване на двата свята (стария и новия). Първо ще има pipeline, демек инструкциите ще се извличат и декодират както при днешните машини. Обаче след декодиране ще има нещо като "компилиране" до микрокод. Както в доброто старо време оп-кодовете ще се нещо като език на високо ниво, а по-прости микрокодове ще управляват карантиите.
На пръв поглед това няма голяма логика, и наистина при последователно изпълнение на дадена програма няма да има ефект. Но трябва да се има предвид че "компилирането" и "изпълнението" са асинхронни и компилирането може да е условно и освен това при разпознаване на цикличен код може да се променя начина на компилиране.
Примерно кода от първия ми пост: r0, r1, and, r2, r3, and, add
Нормално ще се компилира както биха се компилирали 3 инструкции и ще се изпълни за 3 клока.
Ако обаче тоя код се зацикли с for()/while() и освен това има налични повече от 1 АЛУ - би могло различните инструкции да се разхвърлят и да се изпълнят по-бързо.
При първата итерация няма как да стане да се разпознае всичко правилно, то има ама ще стане много сложен CISC... Докато на следващите итерации вече има повече информация и време за анализ.
Естествено, дълбочината на анализа ще е малка, колкото да се "хванат" елементарни цикли. Най-елементарния от които е memcpy и вече може да се помисли за по-сложни обработки необходими за кодиране, компресии и т.н. Идеята е елементарни обработки върху стриймове да се извършват за минимум брой тактове (по възможност 1). Затова са и двете даннови шини към ядрото - да може да се преточват данните от едната шина към другата с лека обработка от няколко инструкции по средата. Като след първата итерация инструкциите се разпаралеляват и "претакването" на туршията се ускорява

Miro_act не си ли се замислял за ядро, дето компилатора му зарежда микрокода, в зависимост какво трябва да прави. Също така и за динамичен избор на използваните шини, така че спрямо нуждите на програмата да се избира от къде и колко ще са данните и къде ще е резултатът. Ако говорим за микроконтролер, това да има 2 или 3 адресни шини за данни и една за код няма да е проблем. По този начин ще може да изпълни инструкция примерно от вида ADD A,B,C ; където А,В,С за в RAMа, и то за 1 цикъл, но ширината на инсрукцията ще е голяма, смисъл код, и 3 опреранда (поинтера); от друга страна ако имаме 3 указателя за A,B,C инструкцията ще е доста по къса, само опкода. Така че ако можем да конфигурраме ядрото на MCUто според нуждите ни ще е досто удачно. Също така не е за пренебрегване възможност за създаване на логически таблици за фунции - в 1 цикъл да се смята CRC. Няма да е излишно и на всяка инструкция да се задава размера на данните, смисал ако ядрото е 32 битово и работим с 8 битови данни губим памет и не печелим нищо. Според мен може да се направи някакъв хибрид между MCU и FPGA.

Gosho, не те разбирам май... и ти май не ме разбираш, затова ще пробвам да обесня пак.
Идеята е инструкцията да е примерно един байт, който кодира да речем ADD операция но не кодира операндите. Знае се само че ADD взема 2 операнда и връща 1 резултат.
Какви са операндите - ами пак инструкции
Всичко може да се разглежда като еднобайтова инструкция - примерно Rx е инструкция която връща стойността на регистър, а [Rx] може да връща паметта на адреса сочен от съптветния регистър.

Ако искаш да направиш събиране в паметта ти трябва нещо от сорта:

[Ra] = ADD [Rb], [Rc]

което като кодиране би трябвало да се представи като:

[Rb] [Rc] ADD [Ra] MOV

което в буквалния смисъл са си 5 инструкции всяка от един байт. Но още на първия пас при декодирането лесно могат да бъдат сведени до 2 инструкции които да се изпълнят за 2 клока.
Защо не 5 клока - ами защото е възможно да се оптимизира
Защо не 1 клок - ами паметта е 32 бит и няма как да извлечеш 40 за един клок, че да ги и анализираш
Така че нормално тая последователност ще се изпълнява за 2 клока.

Конкретно тая операция няма как да се оптимизира дори в цикъл, защото предвиждам само 2 даннови шини. Ако не използваше 3 адреса едновременно, евентуално би могло като се вкара в цикъл, ядрото да я смачка за 1 клок. Само първата итерация на цикъла ще бъде 2 клока...

В общи линии разбирам за какво говориш. Но именно нещо подобно с индексите си мислех и аз. Щом Ra,Rb,Rc са инструкции, то защо не ги тълкуваш като допълнителна част от ОПКОДА на ADD, пък и този MOV в края ми се струва че може да стане по подразбиране, то ясно че ADD че връща данни. Така инструкцията ще добие 4 байтов формат. При 32 бита памет за 1 клок има шанс да стане, ама с много усложнена структура на адресиране.

След като няма операнди, а само инструкции как предлагаш да става предаването на литерали?

http://en.wikipedia.org/wiki/Transputer
http://en.wikipedia.org/wiki/Charles_H._Moore

Хвърли им по едно око ако не са ти попадали.

Всичко е относително - ако искаш ги тълкувай като част от опкода. Въпросът е че опкода не съдържа информация какви са операндите и колко байта заемат, съдържа информация само че са 2 на брой.
Може да го наречеш че инструкцията ADD е с променлива дължина, ама според мен е по-чисто ако се разглеждат като независими инструкции, т.е. произволни инструкции зареждат предварително две числа в стека за данни. След това еднобайтовата инструкция ADD взема двата елемента от върха на стека и връща един като резултат.
Най-простата имплементация на това ядро би била нещо като RISC с еднобайтови инструкции, всяка от които се изпълнява за 1 клок и няма връзка с другите. Така хардуера би бил много прост, но горната последователност от 5 "инструкции" би се изпълнила за 5 клока.
По-добра имплементация би разпознала "веднага" че може няколко инструкции да се правят в паралел и да 5-те да се изпълнят за 2 клока общо.


да, ясно е че връща - всички ще връщат, ама в стека за данни/операнди.
По подразбиране обаче, резултатът от предишната инструкция може да позва като операнд за следваща инструкция (която изисква такъв). Така че има нужда от MOV - защото няма как да се "поредположи" че искаме резултатът да бъде записан нейде другаде...


Ахъ, ще стане CISC, ама не това е идеята....
Предпочитам ADD инструкцията просто да прави събиране на две числа, без да я ограничавам откъде се вземат те...


Хората са измислили различни варианти. Най-простият е *РС++. Друг вариант е както при ARM - няма литерали, всичко е данни които се извличат индексирано по кой да е регистър. Всъщност има литерали, ама до 1 байт завъртян на N бита...

абе,
като ходите по слъцето си слагайте шапки
и като седите на плажа си мсилете за бира, а не за архитектури
дано ви мине скоро...

Няма надежда... дофтора каза че е нелечимо

знам...
в същност симптомите заглъхват сами с възрастта.
но пък се появяват други.
на мен доктора ми каза да си карам мотора. мнооооого по-добре било да умра от него.
няма да се меся повече в темата.

ако го добутате до битстрим, може да се пробвам.
ама да портнете и gcc

ами тогава не бързай да яхваш мотора още Аз тая идея я имам от 15-на години и виждаш докъде съм я добутал