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

Няма сериозен ОС, който да няма концепция за драйвери. В такива случаи най-подходяща е концепцията с общ IRQ хендлър, който ОС да прихване веднъж и след това да извика съответната драйверска функция. NVIC-а за АРМ 4-6 архителктура е просто прекрасен в това отношение. Друг е въпросът е че хората пищяха тъй като не ползват читави ОС-ве на АРМ7 а повечето изобщо не знаят какъв е смисъла на хендлърите...
Връщането към директни вектори при 7-а архитектура (кортекс) е определено стъпка назад.
Що се отнася до вложени прекъсвания и т.н. старата имплементация също е по-добра!!
За влизането в прекъсвания също може мнооого да се спори. Щеше да бъде хубаво, ако ония 12 клока дето ги рекламират бяха истина и ако нямаше проблем с прекъсване на условни инструкции, подравняване на стековете и т.н. Процесорните режими също са леко недообмислени...
Относно атомичните операции - LDRЕX/STRЕX е стъпка напред. Игрите с битовата адресация обаче не са полезни и ако погледнеш почти никой не ги използва. А това за "bit test and set if clear" сефте го чувам




Да, има - инструкшън сета е много по-гъвкава. Ядрото е значително по-бързо особено спрямо АРМ7, в това число и работата с паметта. Като цяло е по-добре, но заради прекъсванията, а въпреки тях




Така е, но само умножение при куртекс е 1 клок - винаги. За МАС събиране/изваждане разбира се още 1 клок.
При тоя MIPS обаче чистото умножение е 2 клока принципно, но доколкото разбрах благодарение на конвейра май се смъква до 1 клок ефективно.

Тъй че в общия случай според мен двете ядра ще са еднакво бързи. Само при някаква по-буйна математика, ако компилатора не може да подреди инструкциите евентуално MIPS-а ще си задръства конвейра и ще бъде маалко по-бавен... При куртекса такава опасност няма, но пак казвам че това е нищожно предимство...

Далеч съм от намерението да сравнявам две ядра, дето не съм ползвал и не възнамерявам
засега да ползвам, та да им се задълбавам.

Това, което знам от опит - доста над милион реда - е разликата между това
да имаш 16 регистъра (без малко при АРМ) и 32. Има ситуации, и то не рядко, в които човек
може да се възползва от 32-та и съществено да бие 16-те.

А какви ще ги свърши компилаторът ако човек маже на C е разбира се далеч по-неизвестно
от разликата между 16 и 32 така че тоя аргумент в масовия случай е невалиден.
Но то в тоя случай така или иначе се сравнява какво е намазал компилаторът, трябва да е
много крива архитектура, като x86 или тия пикове без стека, за да има съществено значение самата тя.

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

@tqi,

Ако искаш много проста RISC архитектура ще стигнеш до нещо от сорта на АРМ7 - 32-бит ядро, способно да изпълнява почти всяка инструкция за 1 клок и закачено на една 32 бит шина.

При подобна конфигурация най-оптималният брой регистри е 8 (осем). Причината е, че ако избереш 32-битови инструкции шината ти се оказва тънко място - 100% натовареност само за извличане на код, ами с данните кво правим?
Това е една от причините да се използват 16-бит инструкции - така шината ти остава на ~50% свободна за даннов трафик. Да де, ама за да кодираш в 16 бита някъде 50-100 различни инструкции с по 3 регистъра, трябва регистрите да се кодират с 3 бита... Демек осем на брой. Другата причина да се ползва (16-бит thumb) разбира се е размера на кода - просто става по-кратък..

Те така за подобна евтинджос архитектура (без кешове и т.н.) каквато е АРМ7 няма голям избор. Те всъщност са сложили повече регистри, с неудобството че не могат да бъдат използвани навсякъде. Това пък допълнително обърква компилаторите. Затова при АРМ7 аз вземам мерки да огранича компилатора да не ползва повече от 8 регистъра
Другия аспект е че това все пак е контролер и то обикновено с много периферии и много прекъсвания... Съвсем нормално е да имаш няколко прекъсвания за една милисекунда, което често води и до смяна на контексти. Повярвай ми, много по-лесно е да спасяваш само 8 регистъра. Примерно при натоварена система мога да стигна до 10к смяна на контексти в секунда. Ако бях с още 20 регистъра отгоре, това са ти 20 писания + 20 четения (* 4 байта) по 10к = 1.6 MB/s. По твоите разбирания това е нищо, но не забравяй че става дума за система която работи на нисък клок. Аз обикновено не минавам 10MHz, a скоростта на memcpy() е под 10 MB/s тъй че 1.6MB/s не е чак толкова малко за тия мащаби.
И още нещо - тъй като клока е нисък и обикновено се работи с SRAM, то дали ще ти е в регистър променливата или в паметта на практика няма никакво значение

Сега при АРМ9 шините вече стават 2, освен това кешът е задължителен. Тъй че тук няма чак такъв проблем с фетчването. И все пак те шините две, ама често към една и съща памет... Освен това като туриш и нещо от сорта на LCD контролер пак се натоварват нещата. И дори при АРМ9 16-битовите thumb инструкции дават предимство....

При куртекс вече има 3 шини и тайминга е изстискан до дупка. Примерно записите почти винаги се изпълняват без наказателен клок. Но и тук 16-битовите инструкции са от ключово значение. Щото ако паметта ти е една многото шини не помагат.

Та с две думи, при АРМ регистрите са 8 и са си оптимални като бройка. Не може повече, а и няма нужда... примерно последното дето правих на асемблер - sprintf и scanf функции ги правя с по 7-8 регистъра без стек или други променливи. malloc() с 6, free() само 4 ...

Многото регистри не значат, че трябва да ги спасяваш при всяко прекъсване.
Затова и операцията е оставена на програмиста.

Аз най-редовно стеквам само 2-3 регистъра в прекъсване. Превключването на контекст е
съвсем друга работа. Примерно в DPS-а реакцията на прекъсване е някоя-друга микросекунда
(много под 5 при сума ти невложени, под 1 ако става дума за едно), докато превключването на
контекст струва десетки (не съм го мерил, то няма отношение към критичните по скорост неща, на
око бих казал 30-40). Но при натоварена система рядко изритвам някого преди да е имал няколко милисекунди.

За малкото регистри и кратките опкодове съм съгласен по принцип, 16 бита
опкод е по-кратък от 32. По-сбит 16 бита код от 68k едва ли има (но те не държат три регистъра
в една дума), е него без оптимизация като го асемблирам за power става към 3.5 пъти по-дълъг
(най-вече заради непрекъснатото ненужно повечето време поддържане на carry бита).
Като го оптимизирам на ръка става от почти същото до 1.5 пъти (на око говоря), та не е
кой-знае колко голяма разликата (каквото пиша го пиша отдавна оптимизирано за power).

Но огромното намаляване на размера на кода идва от това, че пиша от по-ниско ниво;
в тоя новия анализатор целият DPS, с прозорци, мрежи, файлови системи, ОС команди,
редактори, че дори и спектрометричния софтуер се събра в по-малко от 2М flash
(почти целият е като диск, 64к са каквото другите наричат BIOS; може да се бутне от
него, то и няма откъде другаде ако HDD е небутваем - нов за инсталация, засран и т.н.).

Ако става дума за скорост с 32 регистъра човек може да пише по-бърз код отколкото
с 16, да не говорим за 8. Писал съм и с 3 (6800 - a,b,x, sp не го броя), и с 6 (6809 - a,b,x,u,y,s,
s го броя щото е и индексен/адресен), и с 16 (68k) и с не ми се смята колко бяха в 54xx, то
е едно странно такова, и с 32 в power (+32 FP). Многото регистри са по-добре.
Най-елементарен пример, местене на памет (търкаляне на екрана, примерно
800 на 600 точки прозорец, 16 бита на точка, към 1М идва) - най-бързо стана като го
направих да прочита *всичките* 32 64-битови FP регистъра и ги пише пак всичките 32
където ще ги пише. А не е да няма сгънати branch-ове с брояч вътре и подобни, в такъв сгънат цикъл
става забележимо по-бавно. Не пъти по бавно разбира се, но беше бая по-бавно.
Другото очевидно предимство на многото регистри е това, че човек много по-малко
трябва да ги пише и чете; просто на практика винаги всички променливи могат да си
стоят в регистрите. С 16 понякога не е така, а 8 са си направо малко. Това е и причината
през 80-те да излезе модата на RISC процесорите, нищо ново не казвам, само го
потвърждавам от опит .
ARM обаче изглежда много добре са хванали границата между двата свята - на големите
и малките, сякаш това им е номерът в живота.

ATMega, ATMega, ATMega....? Темата беше за 8 битов контролер който даже и четвърт бит няма реално налични. Вие пак си го довлякохте до ARM/PPC/PIC32. Точно като оня с краставиците.

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

За АРМ9 кеша не е задължителен - арм966е често е без кеш (незнам дали има вариант с кеш) - вярно че има ITCM и DTCM, които са си бързи, на клока на ядрото, но не са кеш.

Не искам да зесегна автора - аз лично нямам опит с писане на ОС - само ползвам, но се интересувам какво ползвам.
Та значи не знам как е при МИПС, но от АРМ само при кортекса ОС няма нужда от забрана на прекъсванията, никъде в системните му функции. Нима за една ембеддед (real-time) система това не е съществено предимство?

Отностно бит тест и сет иф клеар - именно тя е основата да направиш заключване без забрана на прекъсване.

Peace!

Ама наистина ли се казва "bit test and set if clear"? Инак е нормално да има
такава инструкция, в 68k се казва TAS - "test and set", и прави непрекъсваем бъс цикъл.

Нещо в тоя ред трябва да има във всеки ARM? Не мога да си представя, че няма (не ги познавам де).
По-рафинираният метод - който избягва усложненията от заключване на бъса, което не е никак
малък келепир - е като в power, lwarx/stwcx. комплектът. Два отделни цикъла са, но след втория
знаеш станало ли е непрекъснато или не и ако не, повтаряш.

Разбира се, че основното определящо скоростта на реакция на дадена система е латентността
откъм прекъсвания, разните RTOS производители като почнат да говорят за време на превключване
на контекст нещата отиват по-скоро към маркетинг. И разбира се, че в системните функции
практически никъде не се налага човек да забранява прекъсванията.

Сори пич, ама мен ми плащат да ги знам тия работи тъй че ме засягаш

И тъй като аз не знам за ОС, който да не забранява/ограничава прекъсвания, значи казваш че не съм си свършил добре работата





И такова нещо не съм срещал, ама щом казваш....

Не съм сигурен дали се казва така, но по спомен си има атомик инструкция за спин-лок - дали е било използване на LDREX / STREX, или ползване на бит-банг зоната (или комбинация от двете), но в крайна сметка резултата си е лок без забрана на прекъсването.

PowerPac на IAR го ползват, и се водят със "Zero intrerrupt-delay" (на ОС-а). Има и open-source версии, които ползват ефективно новите инструкции (колко са нови, като се ползват от 2003 някъде, не знам).

Моят извод е, че модела на работа на кортекс се отличава от старите арм7/9 и съответно концепцията е по-друга. Това не значи автоматично по-добра, нито по-лоша - просто различна.

Пак да се оправдая - не съм писал (или портвал) ОС за кортекс, така че просто изтъквам това, което знам . А и не смятам че ми е работа - има смисъл от това, ако работиш за фирма, където ОС се вгражда в толкова много устройства, че да си заслужава труда. Или ОС да се продава на други фирми че бройката да излезе. Не знам в БГ да има такива проекти, но някой хора (и аз) работим и outsource. Лицензът на добри (разбирай - направени, тествани, документирани и съпортвани, а и с опция за safety сертифициране) ОС е колкото издръжката на един кадърен инженер за 0.5-1-2-3 месеца.

Ако работата на колегата miro_atc се предлага като продукт на пазара, бих се заинтересувал да я разгледам, а може и да я ползвам един ден. Може пък накрая да има някакъв ефект от темата, било то и да не решим ДМА казуса.

Няколко линка:
http://www.coocox.org/CoOS.htm
http://www.segger.com/cms/embos-for-cortex-m3-cpus-and-rowley-compiler.html



Peace![/url]

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

Иначе аз до преди около 2 години предлагах ОС като продукт.. но това може да се нарече провал. В смисъл нямаше никакъв интерес, въпреки че го предлагах абсолютно фрее. Вече не предлагам нищо... но ако е само за любопитство тук може да разгледаш някои неща (сори старо инфо, но...).

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

може, ама вече не е само мой...

Май съм голям кърък на тема DMA...

@tqi, заглеждал ли си се по MCP8308 или подобните нему? Нещо не мога да вдяна как се прави хардуерно ДМА по локалната шина... Обичайните заподозряни DMA REQ/ACK отсъстват

Локалната шина има някакви user-programable machines - да не би туй да е ключа към палатката? Търси се начин да се точат повечко данни от външно устройство, но да е с хардуерен хедшейк щото с прекъсвания ще стане много грозно....

Не го знам тоя. Знам в детайли тоя на 5200 - ама той е интелигентен, едва ли е същото.

Но обичайното DMA req/ack от едно време не съм го виждал много отдавна, и преди 10
години го нямаше в 8240.
Ако търсиш такова DMA, дето в един цикъл прехвърля периферия <-> памет, докато
процесора го няма, забрави. Не съм виждал такова от много поколения насам.
Правят ги като отделен бъс мастър, който се арбитрира като всички други за бъса,
чете откъдето ще чете, и после - може би след още едно арбитриране - пише където
ще пише. Което не е толкова зле, щото като се набърсти успява да набърсти и DDRAM-а
и т.н., слагат FIFO-та от 512 байта нагоре и скоростите са близко до теоретичния
максимум. Но трябва да му баеш понякога за да се разбърсти.
В 5200B (не в недоправения оригинален 5200) има и GPIO крака, дето могат да
бъдат DMA requestor-и. Което ще рече, че от тоя крак тръгва заявка, а после на сума
ти места отделно се програмира какво ще става, къде ще буферира и т.н., сума ти
детайл е.

Ако срещаш някъде думички като "SDMA" или "bestcomm", може и да имаш късмет и
да е същото SDMA от 5200. То е много трудоемко за разбиране но аз вече го знам и
имам каквото трябва за него (инак за широката публика се очаква да ползва някакви
готови микрокодови бози дето не стават за нищо).