> Да какая разница, кому пришло в голову поработать так? Ты привел это как типичный код. А я возразил что по состоянию на сейчас это нифига не типично.
Ну вот смотри, вон та мипсятина своим линухом цепляет вон тот pcie ath9k ничем не хуже чем на x86. Удачи в outb на том мипсе... у него таких понятий нет! :). А линуксные дрова вот работают. Запускают те же pci-шины, те же железки на них, тот же usb EHCI, те же железки на них, ... и тот же линух там идет на взлет. И с ARM или PPC такая же фигня.
Пойнт в том что оперировать x86-only спецификой, которая к тому же давно считается за махровое легаси эпохи ISA как примерами работы с железом - отстало лет на 20. И наверное не стоит так иллюстрировать работу с железом. Дабы какой-нибудь неокрепший ум потом не попытался сдуру сделать именно это, именно так.
> Главное что ты посмотрев код, работающий с железкой, не узнал ничего нового:
> всё что можешь ответить на поставленный вопрос -- то же самое, что ты
> можешь ответить не глядя в код,
Э нет. Если я не имею даташита и не видел сорца работающего с железкой - я о железке вообще ничего не знаю. Реверсить совсем вслепую - крайне мучительное и медленное занятие, сильный якорь в разработке. А вот сорц может дать мне знание ключевых регистров и их составных частей. Это знание может быть урезанным относительно того что есть в полном даташите, но для базового понимания железки и ее запуска худо бедно хватит. И это уже большой шаг вперед относительно копания вслепую.
Алсо, бывает инверсная проблема. Даташиты бывают написаны мутно, неточно, непонятно, а то и попросту с багами и логическими противоречиями, а то и просто quirks которые не документированы в даташыте. И получив на вход такую доку может быть не очевидно как на самом деле с железкой надо работать. Или написаный по спекам код не заработает. Или будет работать не так как задумано. Потуги писать по той доке код обречены на довольно много мучений. С другой стороны, сорец, если известно что он работает - это финальный ответ на данный вопрос, окончательная ауторити. Если вон те действия ведут к вон этому результату и это проверено кодом, который, желательно, активно гоняли - значит делать вот так и правда катит.
...но чтобы это узнать надо, очевидно, взять даташит и попытаться написать работу с какой-нибудь железкой по этим спекам. А ты это когда-нибудь вообще делал? Нет, поюзать чужие либы и дрова как черный ящик - не о том.
> то есть пытаться обесценить вопрос, доказывать, что вопрос не заслуживает
> ответа, рассказывать про математика-теоретика, который в отличие от умного тебя
> туп безбожно и ничего не понимает в железе. Но на вопрос-то ты не можешь ответить, а
> не математик, так? ;)
Я лишь усомнился что математик-теоретик сам пробовал накодить работу с железкой по спекам в своем коде. Nothing more, nothing less. А усомнился я в этом потому что мне показалось что человек не в курсе некоторых тематических "приколов" области, но лезет с умным видом рассуждать. Честность за честность? :)
> И да, не над оскорблять операции сложения и вычитания, мол, они только
> математику-теоретику в голову придти могут.
Для именно работы с железками как-то сильно актуальнее операции с битами и битовыми полями, так что опять же пример получился не от мира сего, все что он иллюстрирует - что человек не рубит как это сейчас выглядит, но рассуждает.
> Эти операции не могут придти в голову современному системному программисту,
> которому вдолбили в голову, что если value представляет собой битфилд,
> то его собирать надо при помощи побитового ИЛИ из предопределённых констант.
Если нечто выглядит как битфилд и ведет себя как битфилд, логично работать с ним как с битфилдом.
И да, попытки выпендриться на этом поприще ни к чему хорошему не ведут. Если интересно, почитай книгу Michael Barr - Embedded C coding standard (она легально есть для скачки как пдф). Там описан ряд довольно странных на вид вещей. Смысл которых - минимизировать количество багов и использовать "антибажные" техники кодинга еще на подлете. Ну, просто потому что отказы в эмбедовке, сбои в работе с железками и все такое - выглядят и ощущаются очень неприкольно.
А если выразить идеи вкратце, примерно так:
1) Код должен быть простым, понятным и без выпендрежа. Иначе проект будет проклят багами и глюками, особенно когда ты его отложишь на полочку на пару лет и забудешь свои кулхацкерские фокусы. И тем более когда его возьмет в руки кто-то кто-нибудь отличный от тебя.
2) Не следует раскладывать себе и окружающим грабли. Как минимум без острой на то необходимости. А где иначе ну вот совсем никак - надо тщательнейше документировать. Иначе однажды все сломается - и никто не будет понимать почему.
3) Чем проще код - тем он надежнее. Если ломаться нечему, то уж нечему.
> Хрен тут был и сбоку бантик. value+1 можно
> использовать для того, чтобы установить младший бит, например
Можно! Но это поганая идея. Потому что через пару лет ты и сам лоханешься в оценке чего тот код делал, а если уж в нем кто-то другой будет копаться, он и подавно не врубится.
А теперь сравни с чем-то типа REG_SET_BIT(HW_REG_ABC, FEATURE_BIT_5). Вот тут уже даже полный болван начнет догадываться what's going on. И кстати кто сказал что через пару лет занятий другими проектами ты сам не окажешься в роли того болвана, когда вспомнишь что вот такое у тебя уже было пару лет назад, так что заново кодить не надо? %)
Еще дедушка Кнут сказал же: не надо выделываться если это убивает читаемость и понимаемость кода. И он знал о чем говорит.
> конечно). Можно использовать для того, чтобы сбросить младший бит, и установить
> тот, что постарше.
Как бы это сказать? Вообще, фактический паттерн доступа к вон тому куску памяти при произвольной математике не особо то и определен. А для HW register может влиять даже просто чтение. Ну например бывает что некий статусный бит взводится, а когда прочитали, железо само сбрасывает (ну, чтобы код время не тратил). А писать 1 в этот бит вообще невалидно, например.
А ты там обычной математикой, безбашенно? Так можно получить какой-нибудь жесточайший undefined behavior. В хучшем случае - раз в год, когда твоя чудная абстрактная математика наткнулась на тот выкрутас железки, формально валидный но таким кодом решительно непредусмотренный. На самом деле если такое было - даже REG_SET_BIT той гадине придется сделать свой, особенный, учитывающий это западло. И пойнт в том чтобы оно как раз было безграбельно по отношению к той штуке. А вот абстрактная математика применительно к произвольно взятому регистру железки это мягко говоря не гарантирует.
То-есть одним нехитрым выгибоном кладем нефиговые грабли. Возможно стреляющие раз в год и потому их даже тесты не поймают вот так сразу. А оно надо? :)
> великолепие одной командой процессора (правда похерив флаги). Сегодня так не делают,
> потому что это "грязные хаки", которые выносят мозг неподготовленным, и те
> начинают кричать, что "код нечитабельный".
Более того - это ведет к багам и ломанию дров. В эмбедовке это тупо опасно для жизней людей. В работе с железками на том же PC - тоже мало кто радуется жесткому дедлоку или мощному разрушению данных сдуревшей железкой.
> В 80-е и раньше такой стиль был нормой (не везде конечно,
В 80-е видите ли...
1) Была однозадачность, а ребут вообще зачастую был штатным способом выхода из программы, особенно для non-DOS окружений.
2) Мало кто использовал компьютеры для опасных/чувствительных управляющих процессов, а шишки были еще не набиты. Ариан 5 еще не разбился, fly-by-wire еще не ушел в массы, автоматические поезда и системы управления если и были то в зачаточном состоянии.
А что там раздолбай-хаксор в своей демке/гамезе накодит - да в принципе что угодно, его да даже полный дедлок как максимум обидит десяток юзерей сфлопинетивших это.
Я не спорю что это очень клево и романтично. И все же с тех времен мы основательно обпрыгали многочисленные грабли - и потирая ушибленные лбы поняли что всему свое время и место. В том числе и хакерским трюкам :). И я имею нескромность думать что вот именно в работе с железками именно откровенный хакеризм очень уж чреват side effect-ами. Особенно если есть хоть минимальный шанс что этот код будет щупать кто-то кроме тебя. Да и ты сам через несколько лет можешь уже и не вспомнить все детали. И будет очень кстати если код простой и понятный.
> но на PC я видел немало такого), потому как экономия одной машинной команды -- это
> было хорошо.
Да, есть такое направление. И оно по своему клевое. И btw однажды я крепко хардкорил на эту тему, просто потому что мой модуль тупо не лез :D на несколько байтов в набортный SRAM :D а более крупного RAM внезапно не было - потому что тот модуль как раз остальное и подымал. Это правда был вообще совсем не х86, но идея та же самая. И все же у этого направления есть свои грабли. И довольно болезненные. Это хорошо для игрушечных применений, но если мы хотим немного большего, чтобы тысячи юзерей были счастливы, а то и вовсе доверить свои тушки нашему коду - тогда мысли о том как писать код все же немного меняются. В пользу предсказуемого, понятного и безграбельного кода.
> Писать так было нормой, а если ты умел читать такой код
> и понимать, то ты был крутым специалистом.
Это по своему хорошо и романтично, я не спорю. Я тоже делал некоторые забавные трюки. И сейчас иногда делаю. И все же имею заметить что вот именно в работе с железом это в общем случае - не есть удачная идея. Ну, потому что какой-нибудь дедлок раз в год очень обидная и очень трудноотдебаживаемая шляпа. Демку то что, 5 минут покрутил и вырубил. А если оно год непрерывно вкалывает, люди на это закладываются, и вообще... ммм...
> С портами, сорец скорее всего тоже давал номерам портов всякие хорошие имена,
> это принципиально не меняет ничего.
Это принципиально разные методы работы с железками, при том первый уже давно стал легаси, да и не работает нигде кроме x86. А вот mmaped - да на почти всех современных штуках, от cortex M0 который под микроскопом рассматривать впору до здоровенных серверно-энтерпрайзных монстров.
Вариант для распечатки
