низачем. просто пытался понять как это вообще может работать. сейчас сделал отдельные 2 лексера и парсер

один лексер  хочу переиспользовать

ну нельзя указать путь к файлу, например. как то так себе

ARMv8 более строгий чем ARMv7 и Power.
Основное отличие, сделали таки multi-copy-atomic модель, т.е. все потоки видят как записи приходят в основую память в одном порядке
https://core.ac.uk/download/pdf/132612333.pdf

тут можно посмотреть, как load/store-ы компилятся на разных процессорах
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html

А можете пояснить для несведущих, пожалуйста. У меня есть 3 указателя на объект (хранятся в разных местах). Я создаю четвертый. Как мне одномоментно обновить биты у трех "предыдущих", чтобы они теперь корректно отражали счетчик ссылок? Или я совсем идею не понял?

И почему, если это возможно, аналогичный трюк не работает на интеле?

Не знаю про swift и все такое, но знаю про другие языки.

Все три указателя указывают на объект. Объект это, в сущности, еще один указатель, в старшие биты которого может быть интегрирован счетчик. Или тип объекта. Или инфа о том, что оставшиеся биты это целое число. Или еще какой-нибудь мусор.

вообще, интел просила так не делать, но решение популярное

Тип объекта - - иммутабельная информация, трюк с тэгированием известен. Мне непонятно как обновлять информацию про счетчик у указателей, сохраненных в полях других объектов

Я понял описанную схему как указатели на указатель (вот в нем и хранится счётчик) на объект. Но получается ещё один уровень косвенности

Чем это отличается от flat поля-счетчика в объекте? Если уж разыменовывать придется

о, спасибо!

я видел намеки на это у товарища в твитторе где он пишет "arm and intel models are close enough now".

Справедливости ради, строгость модели памяти можно рассматривать в смысле «не хуже чем указано в архитектурном спеке» И коль скоро память более строга, это можно считать и микроархитектурным изменением - и таки да, такого рода вещь в многоядерной системе должна закладываться изначально, это не добавление одного битика в pstate. В частности, это неиллюзорно влияет на виды сообщений в интерконнекте и внутреннюю логику процессора.

https://github.com/apple/swift/blob/main/stdlib/public/SwiftShims/RefCount.h#L42-L95

рефкаунт лежит в объекте, либо инлайн, либо за указателем на дополнительную табличку.
много% объектов отмирает сразу же без слабых ссылок, поэтому экономия на доп аллокациях, и лишних дереференсах

>>>> неиспользуемые биты указателя репурпознули для счетчика
>>рефкаунт лежит в объекте

Как устроен подсчет ссылок со счетчиком внутри объекта у меня вопросов нет, это классика.
Непонятно, при чем тут тэгирование указателей  (в чем трюк?) и какая хардварная поддержка может потребоваться для этого. Совсем непонятно, что это за трюк такой, что интел в разы медленнее работает.

сорян, у меня тэгирование уже спуталось со всем остальным. длинный день.

надо узнать у эппловцев, есть только замеры скорости.

how can i write abc@abc.com...in regular expression

there is no 100% complete and working regex for emails