11.11.2015 9:42, Чуйкин Андрей пишет:
> Можно (нужно) и просто добавить. Но это слово 'slack'... В контексте
> программирования оно вообще ни о чем. Это как разговор Равшана и
> Джамшута. Вроде понятно, но не серьезно, смешно и совершенно ясно,
> что не родное. Так и со slack. Совершенно неподходящее название
> функции. Помнится мы так и не придумали ничего лучшего. Очень
> хотелось бы его изменить и не смотреть на совместимость. Могу
> предложить многословное, но достаточно точное название:
> calc_free_stack_space. Calc - это чтобы подчеркнуть, что выполняются
> вычисления, требующие времени. Остальная часть названия и так
> понятна.
Слово не нравится... :) Ладно, давай поговорим о словах (в конце каждой
фразы подразумевается смайлик).
Посмотрим на calc_free_stack_space. Начнём с calc. Сразу вопрос: зачем
подчёркивать, что это, типа, вычисляется? Какую полезную информацию это
несёт? Внутри процессора постоянно что-то вычисляется, так надо ли к
каждой функции добавлять префиксом calc_? Кроме того, если вникать, то
выяснится, что эта функция на самом деле ничего не вычисляет, а просто
проверяет - чекает - "хвост" стека. Т.е. более соответствующим
действительности названием было бы
check_free_stack_space();
Но более коротко и не менее понятно было бы просто
free_stack_space();
т.е. из имени функции по семантическим правилам в программировании ясно,
что функция возвращает свободное_стековое_пространство.
Но и тут не всё идеально. Ведь что это за пространство возвращается? Его
можно поиспольовать? Мы знаем, что проверяется размер/количество,
поэтому надо бы это уточнить:
free_stack_space_count();
или даже лучше:
free_stack_space_size();
Длинновато и не элегантно. Похоже, что space тут вообще лишнее, вот
такой вариант уже почти хорош:
free_stack_size();
Да, три недлинных слова, хороший, читабельный и, вроде, понятный
идентификатор. Но есть одно "но": что может понять из него человек,
который видит это имя в первый раз? Понятно что - функция возвращает
размер свободного места в стеке. Т.е. вызвал её из функции slon(),
получил, например, размер 100 байт, а вызывал из функции mamont(),
получил размер 120 байт (потому что мамонт, пусть, меньше стека потребляет).
К чему я всё это написал? К тому, что выбор имени вообще непростая
задача и тут пресс вариантов, выбирать, оценивать, спорить можно до
бесконечности.
[smile mode off]
Возвращаясь к названию идентификатора. Т.е. имя хорошее, но сходу вводит
в заблуждение, не отражает сути. Ровно так же, как и все перебранные
выше варианты. Надо ведь тут подчеркнуть, что не просто свободный размер
возвращается, а размер области, куда ни одна функция ни разу не достала.
И вот как это коротко, ясно и красиво описать?
Я думал над этим вопросом ещё тогда, когда делался нынешний вариант,
т.е. в релизе версии 4. И все эти free, stack, space, count, size и
прочие более-менее устоявшиеся в качестве терминов слова рассматривал,
перебирал... Ничего внятного, точного и эстетичного, другими словами -
адекватного, не придумалось.
И тогда я вспомнил про термин slack. Это слово в качестве термина очень
широко применяется в области проектирования цифровой техники
(ПЛИСоводво, ASIC'остроение - HDL/FPGA/ASIC Design), а именно в
статическом временном анализе (STA). Там оно служит для обозначения
запаса по времени при оценке быстродействия.
Когда я столкнулся с этим в первый раз, то оно меня озадачило, я не знал
этого слова (никогда до этого не попадалось). Полез в словарь, там перевод:
1) провисшая верёвка; слабина
Take up the slack of a rope! — Подтяни провисшую часть каната!
2) а) бездействие; безделье, пассивность, инертность
б) ; спад деловой активности; затишье (в торговле)
3) = slack water
4) дефицит, нехватка, недостача
Думаю: "Фигня какая-то, какое отношение это может иметь к времянкам в
ПЛИС?! Какие такие провисшие верёвки? Какие такие бездействие,
пассивность?.." Стал думать, вникать в суть. И понял. Термин
используется именно в смысле "слабина" - запас. В контексте STA это
"слабина"-запас по времени - т.е. сколько ещё остаётся нано- или
пикосекунд в запасе у сигнала, когда он достиг целевой точки. Т.е. это
разница между заданным временем распространения сигнала и физическим.
Если слак положительный, то сигнал успел (всё хорошо), а величина слака
показывает количественную оценку. Если слак равен 0, то "верёвка"
натянулась - запаса нет. Если слак отрицательный - "верёвка" лопнула,
это фатальное нарушение.
В нашем случае я просто позаимствовал это слово. Это очень точный
термин, он обозначает не величину остатка (времени в STA или стека в
нашем случае), а именно слабину-запас. Честно говоря, я не проверял,
относится ли этот термин к программированию - я подтянул его просто по
смыслу, по аналогии из STA. Обсуждая вчера в личке с Антоном
адекватность этого термина, получил от него нагугленную ссылку:
http://universal_en_ru.academic.ru/259476/RAM_slack
"RAM slack
Компьютерная техника: заполнитель ОЗУ (Это может быть любая информация,
сформированная, просматривавшаяся или преобразованная со времени
последней загрузки компьютера)"
Оказалось, что имеется и некая корреляция. Это те данные, которыми
заполняется память.
Вчера же провёл небольшой опрос среди знакомых: спросил, что они могут
понять из этого имени функции stack_slack(), что она делает/возвращает.
Оказалось, что почти все никогда раньше этого слова не встречали,
полезли в словари. Два человека дали почти правильный ответ: "прострел
стека". На вопрос, насколько этот термин помогает понять суть среди
русскоязычных пользователей и среди англоязычных, мнение было такое: у
русскоязычных есть проблема - они слова не знают, а вот англоговорящие,
скорее всего, проблем не испытают - они слово не анализируют, они его
знают и просто чувствуют его смысл в конкретном контексте.
Итого, как и прежде считаю смысл термина адекватным, удалять из проекта
не хочу. Кроме того, удалять его нельзя - ломать совместимость на таком
уровне уже неприемлемо. Одно дело конфиги насчёт путей поправить, совсем
другое - исходный код в рабочих и стабильных проектах.
> P.S. Откуда у меня эти придирки к словам. Проект публичный.
> Документация ведется на английском.
Документация, вообще-то, на русском. Просто есть перевод
(посредственного качества, но уж как смоглось) на английский. Но
разрабатывалась документация и её основной вариант - на русском, что
естественно.
> Видимо не отрицается продвижение
> ОСи в буржуйское сообщество. Но английский у проекта - это русский
> английский. Для буржуев, хорошо говорящих на нем, это как для нас
> Равшан/Джамшут. Проект не будет восприниматься серьезно с таким
> языком. Документация это полдела. Но если еще и названия функций
> непонятны, то проект рискует так и остаться лишь в небольшом
> русскоговорящем сегменте.
Всё так. Достаточно погуглить, и найдётся немало ссылок на англоязычные
ресурсы. То, что качество перевода документации, мягко оставляет,
желать, я в курсе, но на одном из тамошних форумов чел, который освоил
тему, написал, что, дескать, т.к. авторы из России, то дока написана на
рунглише, но, тем не менее, всё понятно и подъёмно.
Теперь что касается тех двух функций:
uint32_t stack_size();
uint32_t stack_max_used();
Раз уж пришлось плотнее погрузиться в эту тему, то посмотрел и на них
пристальнее. В результате прихожу к выводу, что они не нужны.
Первая не нужна, т.к. размер стека известен и без неё - он задаётся
статически один раз. Для удобства можно просто использовать константу.
Вторая функция - это вообще просто "синтаксический сахар", она
возвращает разницу между указанным размером стека и его слаком. Если
нравится такая функция - никто и ничего не мешает её использовать на
уровне проекта. Библиотека ОС должна предоставлять только необходимый
функционал, иначе проект обрастёт несметным количеством подобного кода,
появившимся только ввиду частных предпочтений. Ничего не имею в виду
таких предпочтений и сам всё стараюсь "подпилить" под свои хотелки, но
делаю это в своём частном окружении. Общая либа должна быть аскетичной -
по возможности только необходимое по прямому назначению.
По первой функции предвижу возражение, дескать, она создаёт
безальтернативное удобство - не нужно таскать константы для размеров,
городить массивы констант для обработки в цикле... А тут простая
встраиваемая функция, которая просто возвращает размер, известный на
этапе сборки, т.е. это по сути одна или две инструкции проца, а возможно
- и просто загрузка размера напрямую (раз он известен в точке вызова),
хорошие компиляторы такое давно умеют.
Поэтому я не против того, чтобы включить функцию stack_size() в код
процесса.
--
HZ