Ми то това си е болежка на всички архитектури май. Кешовете навсякъде са проектирани да са 'прозрачни' за програмиста и на практика няма почти никакви начини за контрол. Хубаво би било ако може да насилиш кеша да зареди или да инвалидира нещо. Особенно с тези микроархитектури които транслират една архитектура до някаква друга, че и разместват инструкции, преименуват регистри и т.н. то е като емулацията във виртуална машина. И най весело става като добавиш в тази картинка няколкото нива кешове, виртуална памет, пара-мега-виртуализации от рода на .нет и джава - т.е. един и същи патерн повторен повече отколкото трябва - вопиющ пример за неефективност и малоумие. Та проблема си е фундаментален и е много надълбоко ...

Palavrov, там говорят за АРМ1 - колко тоя чип е близък до това, което Епъл поръчва като АРМ6 и после АРМ7 и сегашните армове, които сравняваме с х86 архитектурата?

Това сериозно ли бе? На коя архитектура няма инструкция от рода на "invalidate cacheline",
"update cacheline", не говоря айде за по-сложни неща като възможност човек да заключи
части от кеша след като го напълни с нещо? После в разните page descriptor-и не пише
ли тая страница cacheable ли е или не, и т.н.? Не си представям как би могло да
работи реално процесор без такива неща, трябва да си в грешка?


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

Аз продължавам да любопитствам дали АРМ компилаторите са намазани върху x86
такива, ти много по-имаш шанс да попаднеш на улики от мене, ако се случи ще
кажеш. Не че толкова ми е любопитно какви ги мажат де ама ще ми е забавно ако
съм познал какво са намазали без дори да съм ги пипвал .

[edit] Забравих да спомена и на Айк коментара дето иска да слага процесор
за всяка отделна операция и така да промени света. Това работи само в "общи приказки",
в реалния свят процесорите/ядрата работещи по една задача трябва да комуникират
и да се синхронизират, което може да бъде и многократно по-трудно от самата задача... [/edit]

Брех отде почнахте де стигнахте
Обичайно когато се сравнява АРМ vs Intel се сравнява най-високия клас на първите с най-ниския на вторите. И да, от известно време АРМ печелят, за радост на феновете си, но да не забравяме все пак какво е състезанието... От друга страна Интел също не иска да разочарова феновете си и си самоорганизира състезание в една идея по-висок клас. Получава се малко като оня виц за Брежнев и почетното второ място.
Истината си е, че сравнението между двете фирми е като сравнение между ябълки и портокали. Избираш си показател и решаваш кой да спечели. Интел просто държят топ технологиите и по-важното патентите за повечето. Но пък АРМ продължават да скъсяват дистанцията.
Разликите в архитектурите почти нямат значение. И двете си имат много трески както и силни страни. Но практически хардуерният дизайн има най-малък ефект (напук на феновете). Що се отнася до компилаторите, тия които поддържат и двете архитектури съвсем малко са по-добри на х86. GCC е в известен смисъл изключение. Той практически си е отделна губерния. Не е правен за конкретен език или конкретен процесор. Има си фронтенд за езици, всичко се свежда до набор от стандартни операции, оптимизира се и после бакенда разписва инструкциите. Пак се опримизира, после се линква и накрая пак оптимизации. Нещо в тоя дух беше, важното е че се справя горе-долу... По-големият проблем е че GCC практически не генерира нито една инструкция без сорс, докато много от езиците изискват служебни неща. За целта те са изнесени в стандартните библиотеки. И тук вече има бая сериозни разлики. Примерно 64 битовите математики ако няма хардуер се правят софтуерно. Няма лошо, само че АРМ-а не е портнат читаво и кара изцяло софтуерно, дори и когато може да ползва 32-битови инструкции за умножение и деление. Тъпо...
Както и да е, тва беше преди време и в newlib-a, който не е най-добрия вариант за големите АРМ-чета, а и вероятно ще го оправят. Обаче колкото се отива към приложното ниво толкова по-сериозни стават разликите и толкова по-непоправими са. Примерно почти всички сорсове за AES са писани като за х86. Има едни таблици дето се ползват с различен брой ротирания, но за да се спести ротирането всички дублират таблицитв в 4 версии. Да обаче при АРМ ротацията не изисква допълнителна инструкция. Зареждането от таблица обаче изисква. Така "оптимизацията" отива в гъза...На всичкото отгоре се налага да се ползват още регистри и те свършват....и се ползват стекови променливи. А за капак на всичко алгоритъмът е такъв че не подлежи на оптимизации, т.е. компилаторите нямат никакъв шанс да оправят нещата..
Та с две думи разликите и проблемите са най-големи в прилжното ниво, колкото се отива надолу проблемите са по-незначими.

Дедо, нещата са мноооого напреднали
Примерно цинка с който се бъзикам има отделни L1/ L2 кешове за всеки кур, като между кешовете има синхронизация, разни snoop контроли и разни чудесии, така че два кура не могат да видат различни данни на един същ адрес дори и да искат. На всичкото отгоре има фпга което е вързано също към кешовете и може да вади и пъха каквото си пожелае. Може да разшириш инструкшън сета и като видиш къстъм инструкция да си я дръпнеш от конвейра.. Абе бедна ти е фантазията.
Разбира се има инструкции за memory bariers, контрол на кешовете, синхронизация между куровете. Включително и в рамките на един същ кур между нишките имаш ексклусив достъп, така че може да правиш произволни read-modify логики. Тва си го има още в малките М3 куртексчета...
Та така може да имаш колкото си искаш нишки, може да ги пръснеш както си искаш по куровете и нямаш никакви грижи повярвай ми. Без значение че ще бърникат общи променливи, примерно имаш свързан списък и всяка нишка се опитва да вади или слага в него.

Ето ви малко за мазането: http://forum.hwbot.org/showthread.php?t=78490 пачваш микрокода и получаваш 30% производителност отгоре безплано(при неползвания от никого х87)

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

освен това кеша обменя с външната памет на бърстове. в различните DDR-и размера на бърста е различен и може да се избира от няколко размера при DDR, до 2 при DDR2 и в крайна сметка е фиксиран в DDR3. да, ама нито архитектурата на процесора, нито на кеш-контролера е променяна, за да отрази тази особеност.

Renesas пускат куртекс А9 с 3-10MB RAM и ще го има и в QFP корпус..

Ми на тоя дето ползвам напоследък с DDR май са разделно буферирани бърстовете, май откъм
DDRAM-а бяха 8 такта (32 бита всеки), а процесорът е с 32 бита cacheline дължина (и бърсти
все по толкова, то той практически и не се занимава с паметта инак).
Но съм се начел на пожелателни спецификации дори от фрискейл, та това как реално
работят бърстовете и дали няма да се окаже, че работят ама не могат да се ползват "защото"
май освен с опит не може да се каже. Току тая дължина не работела, еди кога си при еди
какво си snoop-ът изпускал еди кой си ред от не знам кой си кешлайн, а бе ако няма продукт
в производство с чип от тия с днешната SOC степен на интеграция може спокойно да се приеме,
че чипът не работи но може и да заработи някой ден. В смисъл за дадена характеристка на чипа
де, човек ако не я види реално работеща няма как да знае работи ли, инак много неща
все ще работят.

[edit] Сега си погледнах поста какви глупости съм броил, още не съм бил баш буден явно.
32 байта е дължината на cacheline-а, което е същото като дължина с това в DDRAM-а;
вярно, че кешът е 64 бита широк откъм ядрото но с еднаквата дължина сигурно си
улесняват живота някак [/edit]

ето какво се получава на практика

това е автоматично генериран код в процеса на само-/крос компилация на gcc

Ново семейство микроконтролери на Атмел

Китайците изтърваха духа от бутилката. Китайския дух де
http://www.microchip.com.cn/community/Library/

(има пълен даташит на PIC32MZ)

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

добре, че краката на чипа все още са на латиница. че като минат на такайски, всичкото кад ще отиде на вятъра...
ще взема да пробвам ментора как реагира на крака с имена като тези
时钟正面一
时钟负一
时钟正面二
时钟负二
алтиума може би ще е по-подготвен

程序存储器 е добре, обаче 数据存储器 не е ли малко? и дали ще може да се пуска код от там?
от друга страна 引导闪存存储器 е неразумно много, но може би е на маска и го бутат във цялата фамилия.
но пък цялата фамилия има 以太网, впечатляващо!
според мен обаче 程序存储器 и особено 数据存储器 ще е малко за пълноценен стек за 以太网 и USB

наличието на 加密 във всички чипове също е нетипично. обаче табличката с времената е впечатляваща:

това наистина ли значи 1.44 ГИГАбита? това също ме впечатли:
•一些功能可以并行执行
тоя 加密引擎 слагат ли го в други чипове?

разбирам защо е интересът към тоя чип е толкова голям. секретността обаче е абсолютна. дотам, че гугъл не знае нищо за PIC32MZ5, какво остава за сайта на мокрочип.

Хахаха, съвсем скоро, Дедо Боре, съвсем скоро.