Тестовете ги правя върху адрес от т.нар D-MEM - локален zero wait state RAM към всяко ядро.
Тествах и върху system RAM, който е закачен към кросбар-а - същата работа.
Прегледах и ератата - нищо по въпроса.
Тестовата постановка я направих в два различни варианта. При единият от тях, няма нужда от намеса с дебъгера. Теста се върти циклично и в брояч се записват успешните lwarx-stwcx. Стойността на броячът винаги съвпада с броя цикли.
Спиране с дебъгер върху брейкпоинт-и по време на цикъла, показва същото: reservation се "разваля" само от stwcx изпълнен от същото ядро.

Баси нещастието, то не работи а те дори не го знаят. Това ядро ако и да е ново не е чак толкова ново но явно е от "новото" време.

Не мога да кажа дали е неработене или не. Но е факт че документите към тази серия MCU-та не са за конкретната имплементация. Досега съм срещал и други "неработещи" неща, които се оказва после, че са описани в общата документация, но не са имплементирани в конкретното MCU.
За да се добера до конкретна документация ми трябваше над месец ръчкане на съпорта на ST и подписване на NDA.
Тук таме съм срещал подобни "нещастия" по форумите на ST и Freescale и за момента съм приел, че някои неща са окастрени поради продуктова политика.

tgi, гледам скрийншота от предният ти пост това е миксиран изглед на твоя асемблер мнемоника и "стандартния" асемблер?

Това е нормално... Идеята на ексклузива е лесна и проста имплементация в условия на суперскаларен конвейр и множества ядра. В старите архитектури атомичността се правеше на база SWAP инструкции, но този подход изисква да се синхронизира съдържанието, т.е. стойността която връщат различните инстанции на SWAP инструкциите. Когато имаш повече ядра или даже само едно ядро с няколко конвейра съответно имаш и няколко копия и няколко пътя към паметта. И е много трудно, ако не невъзможно да се синхронизират стойностите на всички копия. Затова всички заебаха този подход и минаха на ексклузива, при който следиш само последователност на операции, а какво е съдържанието на данните не те интересува. Така софтуера има малко по-малко информация - като ти се счупи последователността знаеш само че е счупена. T.e. zа разлика от свапването, не знаеш кой те е прецакал. Но хардуерът е значително по-прост.
За да е по-чисто и по-лесно следенето се следят само определени определени (ексклузив) операции. Нормалния load/store не се следи. То ако се следяха exclusive load-a нямаше да е необходим.

Виж това, че ексклузива е ексклузив само в рамките на едно ядро е проблем... Но явно e често срещан проблем, щото и при ST-тата както казах имам едни съмнения. Пак ще кажа обяснението ми е, че използват за база ядро без изведен навън екслузив интерфейс и не им се рискува да преправят рутване и т.н. Просто copy&place...

Чиста проба неработене си е, в тоя си вид lwarx/stwcx. не върши работа за нищо. Нали смисълът му е да хване нечие писане - било на
това или друго ядро - между тия две инструкции та условното писане - stwcx. - да не мине и да те уведоми през Z флага та да опиташ
отново.

Това дето постнах е от моя vpa, лист с опция n(ative). native мнемониките са като от power документацията, но подредбата на аргументите е различна, destination е винаги най-десният аргумент, не най-левият както при power (консистентно с по-високото ниво на сорса, което пък води началото си от 68k където беше така). Сорс редовете са тия с номенр, най-отляво.

Моето очакване бе да следят само нормалния Store. Но моето лаишко обяснение е почти като това което описваш.
Ако следяха и нормалният Store, от всички нива на приоритет и от всички ядра(bus master-и)... lwarx-stwcx може да зацикля за неопределено време. Та вероятно това което са имплементирали е продуктивният компромис за ширпотреба.
Но! Всичко това не е написано/обяснено еднозначно за ширпотреба юзър. Напротив, документацията е подвеждаща.

А интересното е че това MCU има и примитиви като SWAP. Това са варианти на Load/Store, които ползват DSMC(Decorated Storage Memory Controller). DSMC има между всяко ядро и шината. Тези инструкции байпасират кеша, но дали това е достатъчно да се синхронизират всички копия и пътища.
Има например CAS инструкция (Compare And Swap). Но са пропуснали да дадат достъп до статуса на тази atomic операция(както при stwcx), което я прави по моето скромно мнение полу-atomic. Защото има поне един случай при който ще се издъни.
Единствената използваема за синхронизация инструкция от DSMC е SWAP, но тя става единствено за multi-core TestAndSetBit. При това от един байт или дума може да се ползва безопасно само по един бит за такъв TestAndSetBit.

tgi, липсваха тук във форума тези сини скрийншоти със специфичния шрифт

lwarx/stwcx. следи *всяко* писане на въпросния адрес. В реалните изпълнения всъщност всяко писане чисти резервацията; и понеже
между двете има само някоя-друга инструкция (може и нито една да няма) няма как да се стигне до вечно зацикляне, ако не първия път
следващия ще стане. Нещата могат да зависят от вида на страницата, кешове и т.н. но ако е write through бих очаквал да
работи без изключения; то и copyback да е пак ще работи нормално но може да зависи от това кое как си конфигурирал да
snoop-и и подобни, вече зависещи не само от ядрото неща.
Ако това не работи нищо няма да работи в система с повече от един bus master. Щом са се напъвали да правят и разни CAS и подобни
ала 68020 неща значи нещо тотално не им е наред, lwarx/stwcx. покрива всичко необходимо, затова и в power
няма друго. Когато работи де.



А пак ще залипсват, обадих се защото като видях поста ти ми се изправиха косите та чак проверих дали нямам подобен проблем
(не че от близо 20 години power при мене dps-a се крепи на това и с всичките dma-та и безумия би имало шанс да работи ако
lwarx/stwcx. не работеше както трябва).

Представи си го от хардуерна гледна точка. Ако имаш няколко памети, примерно в тъпия STM32H7 са 7 региона без да броим тия за код. Тия памети са на различни шини от различен тип, може и да са на различен клок. Отделно ако имаш няколко ядра и всяко с по няколко конвейра (инструкции/клок) и по няколко кеша и става манджа с грозде.
Може да имаш висящи писания на 100 места. Даже и да бяха в един клок домейн е сложно, а те обикновено не са. Как се сравняват данни от различни клок домейни? Точно никак... няма как да се направи.
При синхронизация между клок домейни номерът е да работиш с 1 бит, т.е. с един сигнал. Само еднобитов сигнал може да прехвърляш от домейн в домейн без да се притесняваш от клоците. Може да го семплираш правилно по всяко едно време. Докато групичка от битове, примерно адреса на писането може да се семплира само по фронта на неговия клок. В останалото време семплираш глупости. Да, може да се прехвърля през фифо или друга примитива, но когато примерно единия домейн е избримчен на 10 пъти по-висока честота става пълно мазало...
С две думи - пълно безумие. Няма как да се сравняват адреси между ядра и да се синхронизират. Теоретично вариант е да се сложи специален контролер преди паметта, където заявките са сериализирани вече. Но първо тоя вариант не е удачен при контролери, които ползват няколко памети. И второ това че паметта лесно ще отсее валидното писане е само част от решението. Ядрото също трябва да знае дали писането е минало, което ако се направи се чупи load/store философията. Демек връщаш се на read-modify-write философия. А то идеята е да се избяга от нея, за да не се спъват конвейрите.

Просто трябва нормалния Store да сваля резервацията мисля. Същото което прави и условния Store. Защо трябва да се сравняват адреси и да се правят синхронизации.
В този ред на мисли, едва ли е неопостижимо да се направи, ето при tgi работи.


Товa мисля че са направили с този Decorated Storage Memory Controller.


По моята лаишка логика CAS има резултата от сравнението и е осакатяване ако този резултат не е достъпен за ядрото. Последващо четене и сравнение вече не е част от atomic операция.
Така или иначе DSMC прави read-modify-write, дали резултата ще отиде до ядрото какво ще промени това във философията?


Е, нямах предвид вечно зацикляне.

Е то без хич да се случи да се врътне някой-друг път няма как, или трябва да заключиш целия бъс за всички, което е непрактично отдавна (20+ години),
или така.
Погледнах твоето ядро, те имат не само lwarx/stwcx. (32 бита) ами и побайтово и по-16 битово, стандарното power има само 32 бита (предостатъчно).
Та тия дето са го мислили може и да не са били особено наясно какво правят и да са се оклепали, тия по-малките са безсмислица.
Има и още нещо, говорят, че ако правиш lwarx/stwcx. в cache inhibited район могло и да не работи и вероятно нямало да работи в бъдещи версии,
т.е. може и това да е ситуацията при тебе? Във всеки случай е индикация, че са видели зор да го реализират. А то не е особено зоресто, хората обикновено просто
чистят резервацията ако някой пише някъде, не непременно на резервирания адрес, в споделената памет. Поне в тия с които съм имал пряк досег.

tgi, някак сякаш бяга точния фокус на темата.
Основната цел, една от основните цели, заради които се търси LL/SC двойка е за да се направи lock-free atomic операция.
Като по-високата цел на това е да няма нежелано влияние между отделни процеси, таскове, ядра в една по-сложна система.
Ако всеки, който пише някъде из споделеното адресно пространство, предизвиква нова итерация около LL/SC, то това си е нежелано влияние. В една натоварена система, всяка допълнителна итерация се мултиплицира.
От друга страна пък ако т.нар reservation granule е с размера на една дума, дизайна на хардуера явно се усложнява над практичното.
Изглежда компромисният вариант е LL/SC където само SC(Store Conditional) чисти резервацията без значение дали пише в същия адрес.
Просто моите очаквания бяха други(подведен от общата документация до преди да направя проверката). Така или иначе с определени компромиси и допускания този вариант е работещ за мен. Освен когато става въпрос за повече от едно ядро.
При повече ядра както споменах в нашия случай се ползва - TestAndSetBit реализиран с atomic SWAP.

Да, но де да бях само аз подведен от документацията. Сглобявам и портвам различни части писани от различни екипи, които са писали с допускането че има работеща multi-core CAS операция. Софтуера е портнат скоро за това MCU на ST. И все още никой не е усетил проблема.
За да се уверя че това което търся не е фантазия, проверих как е реализиран CAS при конкуренцията на PPC в тази част на Галактиката - Tricore на Infineon.
Та при Tricore има инструкция CMPSWP.W, която прави същото което прави и CAS при SPC58 с една малка разлика:
Когато CMPSWP.W прави read-modify-write, прочетеното при read фазата се пише обратно в регистъра, в който е била подадена като входен параметър очакваната стойност за CMPSWP.W.

Ето това е напълно atomic CompareAndSwap.

Защото след CMPSWP.W на софтуера вече му е дадена възможност да провери дали това което е трябвало да се запише и върнатото в регистъра където е подал очакваната стойност са еднакви. И това е критерий дали операцията Read - Modify - CAS е минала без да се е намесил някой друг bus master помежду. Това върши същото, което търси моята лаишка фантазия - CAS да ъпдейтне флаг в статус регистър на ядрото, който софтуера впоследствие да провери.

Ако трябва да сравним ябълки и портокали с използването на CMPSWP.W "се следят" само write операции по конкретния адрес от всички bus master-и! И ако някой пише междувременно някъде из споделената памет, няма да предизвика излишни итерации на CAS.
Не знам какво ще спъне това конвейрите или ще наруши философията, но точно това е необходимо в крайна сметка за мултитаскинг софтуера на многоядрена система.

>Ако всеки, който пише някъде из споделеното адресно пространство, предизвиква нова итерация
> около LL/SC, то това си е нежелано влияние. В една натоварена система, всяка допълнителна итерация се мултиплицира.

Не е толкова червен дяволът. Ако системата е толкова натоварена от смяна на бъс мастъри, че да не можеш ако не
от първия от от втория опит да се вредиш за 4-5 непрекъснати цикъла, тя е в киреча така или иначе. Обикновено има
времеви слотове за това кой колко да държи бъса и т.н.

> От друга страна пък ако т.нар reservation granule е с размера на една дума, дизайна на хардуера явно се усложнява над практичното.

Една дума=32 бита (дълга дума за повечето хора е ОК, колко такива ще ти трябват за да заключваш това и онова.
И 100 да са това са 400 байта.
После заключването с цели 32 бита носи добавена стойност в по-големи, мулти-таск мулти ядрени и т.н. системи;
заключвайки когато пишеш в тая дума слагаш в нея и информация кой е заключил ключалката. После ако същият опита
пак да заключи същата просто можеш да му я дадеш - и да му оставиш задачата да запомни, че я е намерил заключена и да *не*
я отключи както би направил ако я беше намерил отключена.

>Когато CMPSWP.W прави read-modify-write, прочетеното при read фазата се пише обратно в регистъра, в който
> е била подадена като входен параметър очакваната стойност за CMPSWP.W.
>
>Ето това е напълно atomic CompareAndSwap.

Да, точно това е реализуемо с lwarx/stwcx. и се прави масово. Просто връщаш прочетеното от lwarx .

Направо ми е трудно да повярвам, че са оплескали работата до степен да не им работят тия инструкции.
В документацията им пише, че работят (отговарят на спецификацията power и т.н., не помня баш думите).
Но или е това или опитваш в cache inhibited район, за какъвто си признават, че не работи.

Не работи кое? Може ли да посочиш къде точно го прочете това.
Прилича ми на още едно двусмислие от некоректно документирано MCU.
Самите инструкции lwarx/stwcx. пише че се изпълняват като cache-inhibited, guarded.
Това което казваш срещам само в "Programmer’s reference manual for Book E processors"
стр. 287, "6.2.1 Memory/Cache access attributes"
Обърни внимание, че това ядро няма MMU и съответно няма TLB. Така че cache-inhibit атрибут на регион на памет в случая е non-sense.

PS:

Под "reservation granulе" имах предвид размера на адресното пространство за което е валидна дадена резeрвация. В моя и твоя случай reservation granule явно е с размера на цял регион памет. Ако въобще е дефинирано.

Ами това видях в RM0004 което намерих на твоя линк някак, май не директно.

На страница 180:
Note the following:
 The memory coherence required attribute on other processors and mechanisms
ensures that their stores to the specified location will cause the reservation created by
the lwarx to be cancelled.
 Warning: Support for load and reserve and store conditional instructions for which the
specified location is in caching-inhibited memory is being phased out of Book E. It is
likely not to be provided on future implementations. New programs should not use
these instructions to access caching inhibited memory.
A lwarx instruction is a load from a word-aligned location with the following side effects.
 A reservation for a subsequent stwcx. instruction is created.
 The memory coherence mechanism is notified that a reservation exists for the location
accessed by the lwarx.

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

>Под "reservation granulе" имах предвид размера на адресното пространство за което е валидна
>дадена резeрвация. В моя и твоя случай reservation granule явно е с размера на цял регион памет.

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

О, това дето трябваше да се изкопае, вече е изкопано. Вече трета седмица оформям документация, имам време и да задълбая в детайли. И за това копнах по-надълбоко.