- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
__attribute__( (noinline,noclone,pure,faNN1_NDA) ) /* DONE */
int arr_findBits0Next( const Array* this_, int idx_, uint num_ ) {
uint _idx = (uint) idx_;
uint _len1 = this_->prolen >> _ARR_PL_L1_RS;
uint64* _data64 = (uint64*) this_->data + ( _idx >> 6U );
if ( UNLIKELY( _idx + num_ > _len1 ) ) return -1;
uint64 _item64 = *_data64++;
uint64 _n = num_;
_item64 >>= _idx & 63U;
L0: _item64 = ~_item64;
do {
uint64 _bit = _item64 & 1ULL;
++_idx;
if ( UNLIKELY( ( _n -= _bit ) == 0 ) ) {
if ( UNLIKELY( _idx > _len1 ) )return -1;
_idx -= num_;
return (int) _idx;
}
if ( _bit == 0 ) _n = num_;
_item64 >>= 1;
} while ( ( _idx & 63U ) );
if ( UNLIKELY( _idx >= _len1 ) ) return -1;
while ( true ) {
if ( LIKELY( ( _item64 = *_data64++ ) != CNST_UINT64_MAX ) ) goto L0;
_n = num_;
if ( UNLIKELY( ( _idx += 64U ) >= _len1 ) ) return -1;
}
}
Кусочек из аллокатора памяти, от "мастера оптимизаций".
p.s. Автор решительно это считает образцовым кодом.
источник http://www.gamedev.ru/code/forum/?id=208332&page=7#m93
Follow us!
L0 L1 L2 - конвенция для лейблов.
Подчеркивание перед именем переменной - она локальная.
После имени - она аргумент функции.
Насчет явного указывания unsigned - GCC любит ругаться на битовые операции и во избежании sign-extention приучился ставить тип в битовых выражения для numeric constants.
Данная функция ищет последовательность нулевых битов заданной длины в битовом массиве.
значит _data64 это длина в QWORD?:)
ладно, я все понимаю, просто у меня конечно волосы дыбом от такого нейминга
Соответственно _item64 это переменная содержащая значение QWORD.
uint64 _item64 = *_data64++;
Слово data означает указатель на массив, слово item элемент массива.
Почему не взять готовую конвенцию? ну вот у MS например есть
там L это Long, P это Pointer итд
я много такого кода в "персонализированом" стиле в своей карьере повидал.
такой код как правило первое что народ викидывает при перенятии коммерческих проектов.
и первое что опен соресы безжалосно переписывают.
потому что никто кроме автора читать/править его не может.
Я бы вот не хотел бы иметь дело с кодом, который оперирует понятием ``_ARR_PL_L1_RS``, но может я просто неудачник
Я верю в силу привычки. Хороший программист даже в личном проекте пишет читабельный код.
С другой стороны без подчеркиваний в длинной функции трудно разобрать какая переменная пришла как аргумент а какая локальная. Ну или опять таки нужно мудрить с неймингами)
а кстати какая разница?
говно конвенция: префикс `_` - это нэймспэйс стандартной библиотеки С.
> Я бы вот не хотел бы иметь дело с кодом [...]
Такой код это просто отражения плохой способности общения. Те кто умеют общатся, как правило пишут более легко читаемый код. К чему веду: плохие коммуникационные способность - крест на росте проекта. Игровой движок одному написать конечно можно... но толку мало, если им никто не пользуется. В мои универские года каждый третий свою игровую систему писал. Догадайтесь что из этого вышло. Ирония в том что именно тот кто этим не страдал (и к слову писал читабельный код) сейчас в близарде работает. :)
Я не полюзуюсь CRT, он у меня выпилен полностью. Ответ устроит?)
Зачем? Что бы оправдать переписывание велосипедов?
Я с радостью перенесся бы в 1985й год и попрограммировал бы под XT, чтобы только я, x86, i8042, i8253, EGA, BIOS и DOS.
мне кажется что ты просто уже забыл тогдашние кошмары.
да было проще. но что-то сделать в 380К памяти (типично что свободно оставалось от 640К базовой без расширителей) было очень и очень сложно.
и опять таки бы понадобился свой аллокатор памяти, потому что досный был открыто неюзабельным. :-)
Никто не забыт, ничто не забыто. Идёт 2015 год, а загрузчик всё ещё можно запускать в реалмоде, в котором даже gate A20 и i8042 с любовью сэмулированы...
Надеюсь, что благодаря UEFI, всю эту мнимую совместимость с DOS успеют закопать хотя бы до моей пенсии...
Молись что не закопают.
Ты забываешь про catch-22 проблему бутлоадеров: загрузить с NTFS драйвер для NTFS.
Решить это можно либо неким абстрактным генерик интерфейсом (пусть и кривым), либо проприетарным, OS-зависимым интерфейсом типа того что используется на Маках и UNIX серваках.
> благодаря UEFI
UEFI решает другую проблему. Или правильней сказать: уже решил. Он убил фатальную зависимость PC hardware индустрии от производителей проприетарных BIOS'ов.
Но даже уже и с помощью UEFI некоторые производители умудрились сделать Windows-only железо: кучи дешевых таблетов (не без помощи мелкософта) в лоб не способны забутить ничего кроме виндов.
Ну проблему с тем, что legacy железо и интерфейсы пора бы уже закопать, он тоже не в последнюю очередь решает. Забавно было смотреть, как 32-битный bios и 32-битный загрузчик делают вид, что совместимы со своими прапрадедами из 85 года... И как bios у материнки, на которой сроду нет ps/2, коряво эмулирует i8042... И ведь вся эта гора костылей совершенно никому не нужна после старта оси...
Да, не спорю, реализации UEFI кривые, бажные, и кроме загрузки операционок на них очень сложно что-то полезное сделать... Но это уже огромный шаг вперёд, по сравнению с тем, что было.
Дык всё хуже было. Всё, что bios поднимает с диска - около 400 байт исполняемого кода. И в это прокрустово ложе надо как-то втиснуть код, который дочитает остальной кусок загрузчика... Какой там NTFS или ext4, туда даже поддержку FAT толком не засунешь... Вот и читали или из захардкоженных мест или через blocklist.
А в UEFI у тебя теперь нет лимитов на размер загрузчика, а все нужные драйвера можно рядом на ESP раздел сложить. Причём дрова для самого ESP раздела прошиты в фирмвари, и ты просто пользуешься интерфейсом (протоколом, ок), тебе даже не надо знать, какая на нём фс (в 99% фирмварь умеет только fat, но всем похуй).
блин. пример кривой дал. правильней пример: "загрузить с жесткого диска драйвер жесткого диска".
> А в UEFI у тебя теперь [...]
Ну это именно то как Маки/UNIX боксы/прочее проприетарное железо это делали уже веками.
Спорить тут не о чем. Но инетрфейсы часто/всегда ОС зависимые. Прогресс не стоит, и следующий ПЦ для Линуха может придется уже самому паять... Прогресс...
Ну да, ещё есть железки, у которых secure boot официально не отключается. Но ситуация ничем не хуже, чем на ведрофонах и ведропланшетах - там тоже почти никогда нельзя загрузить что-то своё без костылей и взлома. Так что эта проблема не только и не столько в M$ и UEFI.
Но у BIOS был хотя бы какой-то но официальный интерфейс. У UEFI его просто нету - потому что каждый и всякий может реализовывать все что угодно. Intel делает только спецификацию. И единственная UEFI firmware certification про которую я слышал - делает мелкософт. (И она требует secure boot.)
Я надеялся что к этому времени все уже успокоится. Но вроде все еще этот момент не наступил. И учитывая что многие производители материнок начали делать специально премиум платы со старым BIOS, честно говоря я боюсь что и не наступит.
Да ты же упоролся. Какой там официальный интерфейс? Исторически сложившийся набор сисколлов и железа из 80х, который десятилетиями просто ссали поменять... С хуевой тучей накопившихся багов, воркэраундов и костылей-эмуляций. По сравнению с этим ёбаным адом, спека UEFI очень даже няшная и документированная.
> требует secure boot
Как что-то плохое. Или пусть ещё лет 30 на PC не будет хоть какой-то проверки бутлоадера на радость загрузочным троянам и кулхацкерам с флешками?
Боятся надо не няшного secure boot'а, а невозможности сменить серты на свои.
Если ты сидел все эти годы под виндой, то я не уверен на что именно ты жалуешься.
Я как линуксоид этого ада реально насмотрелся.
> [...] троянам и кулхацкерам с флешками?
Бут с USB (и других removable media) именно по этой причине пожизненно по умолчанию отключен. Это чисто теоретическая проблема.
Secure boot решает другую проблему: 100% DRM coverage что бы ты п2п-скаченые mp3'ки не мог на своем компе проигрывать.
> Боятся надо не няшного secure boot'а, а невозможности сменить серты на свои.
Боятся?.. Я даже не уверен как на это ответить.
Secure boot просто в жопу убивает поддержку Линукса. Народ там все еще пытается что-то делать (SUSE у некрософта ключики официальные для линуха получила) но оно все еще через жопу работает. или проще говоря: без костылей ни фига не рабоает. Как если бы во времени 20 лет назад перенеслись...
>> требует secure boot
>Как что-то плохое. Или пусть ещё лет 30 на PC не будет хоть какой-то проверки бутлоадера на радость загрузочным троянам и кулхацкерам с флешками?
Ну предположим среднестатистический юзер срать хотел на линупся (а красноглазики пусть страдают), но вот в один прекрасный день его винда перестала грузиться и он нахлобучил загрузочную флешку/сиди, может даже с линупсом. И дальше что?
> загрузочным троянам
Што?
> кулхацкерам с флешками
И что эти кулхацкеры делали с флешками?
> Што?
На текущий момет более теоретическая проблема безопастности, но существует Н proof-of-concept работающих реализаций.
Вирусняк состоит из двух частей: бутлоадер/гипервайзер и основная часть, почти обычный троян. Бутовая часть вируса садится в бутлоадер: грузится первым, делает себя гипервайзером и запускает ОС в режиме виртуалки. Второая основная часть, работающая под ОС, теперь с помощью первой может обойти буквально все защиты ОС.
Маленький побочный эффект что почти все новые процессора поддреживают виртуализацию.
С QEMM было свободно 635К базовой (даже без стрёмного стелс-режима). Правда, не все его умели конфигурировать.
P.S. Не на XT, конечно, а на более новом железе.
C qemm были кучи проблем совместимости. На моем компе он после установки давал что-то типа 530-550К без оптимизаций. А с оптимизациями что-то там что я уже не помню не работало. emm386.exe был отстой, но с ним было меньше проблем совместимости. Я это помню потому что qemm убивал и ставил emm386 для того что бы в SC2 играть, которому было нужно 580K.
PS вы в курсе что SC2 есть для Виндов/Линухов? - http://sc2.sourceforge.net/
В ходе экспериментов я пришёл к выводу, что процедуру оптимизации лучше не запускать, потому что она всё портит. Гораздо лучше к строчкам загрузки в config.sys добавить ключ /B, тогда QEMM будет сам выбирать оптимальные адреса во время загрузки.
Проблемы с совместимостью были только в стелс-режиме (который QEMM как раз и предлагал включить при запуске процедуры оптимизации).
Что же касается свободной памяти, то совместно с QEMM приходилось по максимуму использовать средства самих программ (у самого DOS были ключики в CONFIG.SYS для переноса ядра в UMB или в HMA; у некоторых драйверов были собственные механизмы переноса).
Вспомнил прикольный баг в досе: если открыть emm386.exe стандартным редактором (edit.com или как его там), то начинались интересные спецэффекты. То ли цвета у текста менялись, то ли меню ехало, не помню уже.
ARR - структура типа Array
PL - поле структуры 'prolen'
L1 - оперируем с битовой длинной 'len1'
RS - правый сдвиг (right shift).
Это количество байт с которого начинается значащие биты битовой длины в 'Array.prolen' объекте.
Я бы с удовольствием переименовал, предложите варианты.
uint len1 = Array.prolen >> _ARR_PL_L1_RS;
Сдвигаем вправо на заданное количество битов и получаем битовую длину массива.
Иногда код написан так витеивато, что даже не поймешь сразу что с ним не так
> Вам шашечки или ехать?
эту поговорку цитировать можно только тем у кого код уже "ездить" умеет.
если это часть игрового движка, то я думаю что там до какой-либо играбельной игры еще очень далеко. потому что уже десятилетия как никто своих memory allocator не пишет. а если с такого низко-уровнего начал писать, то до всего более высокоуровнего еще ой как далеко.
да и накой вообще в наши времена нужен новый/свой движок? игровыми движками недописаными и сорс форжи и гитхабы уже давно завалены.
потому что в одиночку что-то юзабельное сегодня, тем более без базовых библиотек, написать просто невозможно. твой код это твоя реклама твоего проекта который тебе надо другим разрабам "продать" что бы они тебе помогли сделать нечто юзабельное. тем более в случае движка: нечто юзабельно разрабам игрушек.
для себя я пишу тоже. конечно. но как правило либо на Перле либо на С++/Qt либо на JS+browser. потому что если я хочу игрушку написать, то я хочу на деталях игры сосредотачиватся - а не байтоёбством страдать.
> потому что в одиночку что-то юзабельное сегодня написать просто невозможно
Возможно, просто нужно мыслить другими категориями. Один человек пишет одну независимую сущность, и не обязательно ею будет программа. Сначала такой сущностью была "ОС", потом - программа, сейчас - модуль, через 50 лет - микромодуль с глубиной иерархии 10.
Польза разделения по людям колоссальна:
1. Каждый может надеть тапочки, чувствовать себя как дома и писать как хочет.
2. Каждый концентрируется на своей задаче и внимание своё не рассеивает на чужое.
3. Каждый знает, что завтра не надо будет ничего мёрджить и тратить время на осознание чужих изменений в своём модуле, т.к. их просто нет.
4. Если модуль проходит тесты, в нём можно не копаться ещё многие годы после увольнения автора.
5. Если модуль не проходит тесты, а автор уволился, переписывать придётся не так много.
Ты говоришь как заурядный прикладник который только one-man-project'ами и занимается.
Ты забываешь про коммуникацию. Конкретней: разделение/специализация разработки влечет за собой образовательную фазу когда нужно объяснить что было сделано, и какую проблему оно решает. Потому что иначе кусок загадочного кода, про который никто ничего не знает никому в ж не сдался.
Ты забываешь про интерфейсы. Компоненты написаные теми кто пошёл по пути "и писать как хочет" гарантировано с друг другом интегрироваться просто так не захотят. Спроси жабщиков которым изредка приходится работать не с одним, а несколькими фрэймворками одновременно: одна хочет данные так, и вывод у неё эдак, у другой все в ж наоборот, и пока тратишь время пытаешься подружить их, основная работа (решение оригинальной проблемы) простаивает.
То что было разделено по людям - рано или поздно нужно будет сводить вместе. И именно на этом концепция одиночного программирования ломается.
Каждый модуль должен содержать документацию. Автор модуля должен ясно описать, как им пользоваться. Поскольку это связано с интерфейсом, который почти стабилен, большой рассинхронизации между документацией и кодом быть не должно.
> Ты забываешь про интерфейсы
> То что было разделено по людям - рано или поздно нужно будет сводить вместе
Да, я не упомянул, что интерфейсы должны проектировать достаточно умные люди (по сравнению с авторами модулей). Все проблемы подхода - от недостатка таких людей и неспособности продумать правильное разделение.
А сводить вместе можно по мере написания. Поскольку во время написания интерфейсы уже известны, каждый создаст модуль, теоретически совместимый с остальными.
С новыми модулями вообще всё гладко: интерфейсы известны, "тонкое" поведение известно - если написал модуль, он автоматически сразу работает.
Как часто ты встречаешь разрабов которые способны хорошие доки писать? Замечал сколько долго они остаются простыми разрабами?
> Все проблемы подхода - от недостатка таких людей и неспособности продумать правильное разделение.
Thank you, captain Obvious.
Недостаток граммотных архитектов проблема всеобщая. Потому что это очень часто те же самые (редкие) люди которые умеют писать человеческие доки. Те же самые люди которые умеют изьяснятся.
> С новыми модулями вообще всё гладко: интерфейсы известны, "тонкое" поведение известно - если написал модуль, он автоматически сразу работает.
... Почитай какие-нибудь книги на тему какие проблемы решают software project managers и software architects. Может поможет проблемы понять.
Я не говорю, что проблем нет. Они есть, но их меньше, чем в случае отсутствия изоляции, когда нужны программисты, которые должны общаться, хорошо знать систему контроля версий, быть готовыми прочитать свой код с внезапными правками от хрен знает кого.
Более уместное сравнение - с дизайнерами, каждый из которых работает в своей комнате. Архитекторы спроектировали дом, строители построили голые стены, а потом в комнаты входят дизайнеры и творят. В общем-то, по такому принципу мы и живём. Купил квартиру - начал делать ремонт, можешь даже двери с окнами вставить не как у соседей. А коли стену решил снести - так надо согласовать или штраф платить.
Или же можно сравнить со зданием организации: это каморка охранника, там только охранник, это серверная - туда вообще никто не ходит, пока всё работает, это бухгалтерия - туда ходят с документами, но не спрашивают, как и сколько бухгалтеров работает.
Этот пример использования называется "юнит-тест"...
Но в практике оно как раз наоборот.
Классический пример: Windows or Mac OS X vs Linux.
Как только ты начинаешь пытаться делать нечто более серьёзное чем helloworld, проблемы интеграции - и количеством, и качеством - в разы перевешивают проблемы кодинга. И очень часто как раз потому что один разраб в своей проге/либе пару строк изменил - и теперь вся система как целое больше не работает.
Как будто что-то плохое.
Допустим, мне нужен хороший парсер HTML.
1. Я создам его, потратив 100 часов, а также буду поддерживать, тратя 20 часов в год. Ещё за 2 часа я напишу код, который его использует. Кодинг перевесил проблемы интеграции в 50 раз, всего потрачено 102+20X часов.
2. Я возьму готовый парсер, потрачу 10 часов на изучение документации, а затем 5 часов в год на изучение документации новых версий. Ещё за 2 часа я напишу код, который его использует. Интеграция перевесила кодинг в 5 раз, всего потрачено 12+5X часов.
Более того, проблемы интеграции возникнут в любом случае. Человек не может охватить и долго держать в голове даже свою подзадачу. Он обязательно разобьёт свою задачу на пакеты/классы/функции и породит задачу субмодульной интеграции. От этого нельзя уйти, какой бы подход мы не использовали (за исключением говнокода на выброс и монолитных кусков для требовательных к производительности мест).
> Но в практике оно как раз наоборот.
На практике подход успешно применяется уже многие сотни лет. Разделение труда, заменяемость работника и множество стандартов - принципы, благодаря которым люди добились многих своих успехов. Мастеров своего дела можно производить в промышленных масштабах, для их координации требуется только небольшая доля ценных междисциплинарных профессионалов.
Парсеры HTML ни в одном проекте проблемой уже не являются. Уже есть стабильный интерфейс (который устаканивался буквально десятилетиями), есть спецификация формата (еще раз пара десятилетий). После того как сотни/тысячи людей сделали все возможные ошибки, и их опыт вылился в существующие интерфейсы и спецификации - проблемы для разработчиков просто уже не существует. Как пример это просто уже не приминимо.
Если хочешь какое упражнение для мозгов, попробуй peer-to-peer networks c mesh routing для IoT, плюс поддержка безопастности - область проблем которая актуальна и где еще нет устаявшихся стандартов и парадигм. Другими словами область где есть работа для разработчиков.
> > Но в практике оно как раз наоборот.
> На практике подход успешно применяется уже многие сотни лет.
Это тебе только кажется, потому что наверное не разу проект от начала до конца не делал. С заказчиками ни разу не торговался сколько они хотят за фичу заплатить (или опен сорес аналог: из криков и ныданий на форумах пытался понять чего от тебя хотят). С дезайнерами нескончаемые митинги планерки не вел - кто что где реализует. С релиз манагемент не трахался, когда last minute change обламывает уже Нную попытку релиз собрать. С тестерами не ругался на тему рабоает/не работает и как оно вообще должно работать и что оно вообще должно делать. С консультантами не пытался подружится которые все еще пытаются кастомерам это счатье проинсталировать, сконфигурировать и запустить. С кастомерами не пытался разговаривать, пытаясь из них дипломатично выцедить что ж бля у них все таки не рабоатет и зачем тебя в 3 утра из постели подняли.
Этот "подход успешно рабоатет" только потому что ты даже не задумываешься кто все эти мелочи за тебя делает. Но это всего лишь маленькая часть всего того что происходит: от идеи до конечного продукта.
Щас человек бросится изучать сети ради того чтобы тебе что-то доказать. Ты не прыщемакака-эникейщик случайно?
Не случайно. :)
А нормальные имена им дать не судьба?
так-с так-с, что тут у нас
Sendmail Configuration Files
...
Table of Contents:
Introduction And Example
A Brief Introduction To M4
СНауТ забивается под кровать и плачет
http://www.lib.ru/SENDMAIL/sendmail_cf.txt
Прокрути до раздела # Правила преобразования #. Там начинается самая мякотка.
Я зову свою беху "Бэшечкой", кому то не нравиться прозвище, мне менять машину? Или прозвище? :)
Там метка /* DONE */ означает что код отлажен, оттестирован, оптимизирован и в ближайшие полвека в него соваться даже мне не нужно.
Полное комментирование того что он делает и возможные ньюансы есть в шапке метода. Здесь их нет.
// [NOTE]:
// - the object is assumed as 'BINARY';
// - the search starts from the specified index and processed till the end of the array.
// [THREAD]:
// - should be invoked from the thread where the object was created.
// [EXAMPLE]:
// int _index = arr_findBits0Next( _arr, 12, 6 ); // Tries to find the '000000' bit sequence starting search at 12th bit index.
//
// @param [Array*] this_ - a pointer on the created object;
// @param [int] idx_ - an inclusive 1-bit index in the backing array to start the search;
// @param [uint] num_ - a number of consecutive zero bits to find.
// @return [int] - a 1-bit index of the first found zero bits sequence with specified length or '-1' value if it was not found or 'idx_' is outside the array bounds or negative.
// @crash [DBG_ARG] - if the 'this_' argument is 'null';
// [DBG_ARG] - if the 'num_' argument is '0';
// [DBG_OBJ] - if the object is 'DESTROYED';
// [DBG_OBJ] - if the object isn't 'BINARY'.
Автор
Ты сделал мой день
Ты же хотел сказать "покрыт тестами"?
Пиздёжь. Ядерный код легко читается. К коду ОП'а ближе всего по читабельности glibc/libstdc++.
2. Если так хочется использовать венгерскую нотацию (или её жалкое подобие), надо вспомнить, что там локальные переменные не обозначаются префиксным _. Наоборот, локальные переменные не имеют префиксов/постфиксов кроме типообозначающих, лишь глобальные переменные выделяются как g_<name>.
3. Твой код потенциально time-critical. Не надо заводить лишнюю переменную для преобразования signed в unsigned. То же самое с (_item64 == *_data64++).
4. Можно обойтись без label'a. Значит, НУЖНО обойтись без label'а.
5. Жесть типа func(a+=b) не экономит такты проца. Выноси в отдельные строки.
6. Именуешь переменные так, что черт пойми что они значат? - хотя бы пиши поясняющие комментарии
7. "Покрыто тестами" и "оттестировано" это очень разные вещи.
Табы вперемешку с пробелами для индентации. Дальше не читал.
Тоже отличный совет. Не, я сам пишу такие комменты после неймспейсов и километровых шаблонов (а остальные блоки достаточно малы, чтобы влезть в экран). Но, судя по примеру, они предлагают лепить это на все подряд скобки...
> Жесть типа func(a+=b) не экономит такты проца. Выноси в отдельные строки.
Путаемся в показаниях?
А оптимизатору похуй на количество переменных, не бойся их объявлять. Он отлично видит время жизни каждого значения.
В данном случае он лишний, да.