Мьютексы, Для того, чтобы вспомнить и улучшить знания Опции

[BRE]

просто юзер не может напрямую юзать аппаратные средства. доступ к некоторым реализован через системные интерфейсы и юзерские API. поэтому для программиста верхнего (по сравнению с системным) уровня аппаратных средств, как таковых, не существует. есть только системные.

Если выбросить ОС, то системных средств у программиста не останется, а аппаратные будут все еще доступны.
С помощью ассемблера программист верхнего уровня может получить доступ к определенным аппаратным средствам. Сделать все те же атомарные операции.

Сообщение отредактировал BRE - 18.11.2011, 11:02

[Iron Bug]

просто юзер не может напрямую юзать аппаратные средства. доступ к некоторым реализован через системные интерфейсы и юзерские API. поэтому для программиста верхнего (по сравнению с системным) уровня аппаратных средств, как таковых, не существует. есть только системные.

Если выбросить ОС, то системных средств у программиста не останется, а аппаратные будут все еще доступны.
С помощью ассемблера программист верхнего уровня может получить доступ к определенным аппаратным средствам. Сделать все те же атомарные операции.

последняя такая система на моей памяти была Windows 98: она позволяла получить доступ к портам. более современные системы НЕ ПОЗВОЛЯЮТ юзеру работать напрямую с железом никоим образом. потому что это просто нарушит работу системы и безопасность.
железо постоянно меняется. причём очень быстро. даже системные программисты не имеют дел непосредственно с железом. на то есть специальные системные вызовы. иначе был бы полный капец разработке: учитывать особенности каждой конфигурации железа и все изменения протоколов по всем устройствам просто нереально. система для того и существует, чтобы избавлять юзера от всего этого геморроя.
конечно, можно снести систему. и работать с железом. писать код прямо в память при старте (а комп без софта умеет только грузить бутрекорд на старте и больше нихрена, ну, есть ещё базовые функции биос, но они актуальны только для получения общей информации о присутствующем железе). но будет очень грустно. особенно потому, что даже система НЕ РАБОТАЕТ напрямую с регистрами процессора. в процессор зашивается микрокод, который сам выполняет множество операций, упрощая и значительно ускоряя работу системы. вообще говоря, при разном микрокоде это будут совершенно разные устройства.
просто я каждый день с такими вещами дело имею. тут всё не так просто, как кажется юзеру верхнего уровня.

Сообщение отредактировал Iron Bug - 18.11.2011, 11:50

[BRE]

последняя такая система на моей памяти была Windows 98: она позволяла получить доступ к портам. более современные системы НЕ ПОЗВОЛЯЮТ юзеру работать напрямую с железом никоим образом. потому что это просто нарушит работу системы и безопасность.

Ну и что? Зачем мне порты для реализации атомарных операций?
Другое дело нужно ли это? Я завязал с ассемблером, когда Пеньтиумы покорили мир, мне стало не интересно соревноваться с компиляторами в оптимизации кода. А до этого я занимался разработкой на ассемблере системного софта, который работал в защищенном режиме. Это времена MSDOS и Win3.1.

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

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

конечно, можно снести систему. и работать с железом.

Если это узкоспециализированное железо, выпущенное штучной партией, то так и приходится делать.
А можно взять тот-же форт.

а комп без софта умеет только грузить бутрекорд на старте и больше нихрена

Не не, это делает BIOS. Сама железка может начать выполнять инструкции из памяти с определенного адрес.

[Iron Bug]

атомарность - не обращение к железу. вообще, ассемблер - это просто протокол общения с процом. некоторые возможности открыты для юзера. когда речь не идёт о вводе-выводе.

это делает BIOS.

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

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

это уже глубокий хардварный оффтоп

Сообщение отредактировал Iron Bug - 18.11.2011, 12:20

[BRE]

атомарность - не обращение к железу.

Это ты начала

атомарные операии - тоже системный механизм чисто ассемблерная фича, даже ещё более приближенная к железу, нежели мьютексы.

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

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

BIOS это обычное программное обеспечение, которое пишет программист, и если вместо него написать свое и прошить его в ROM, то оно спокойно будет работать.

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

Это ты говоришь про то как это устроено в массовом секторе, но есть железки у которых нет ОС и нет такого понятия как модуль ядра в принципе.
Для таких железок тоже пишут программное обеспечение.

[Iron Bug]

Это ты начала

ыхх... сложно говорить с юзерами верхнего уровня!
хардварная атомарность не имеет отношения к вводу-выводу. обращение к железу - это какой-то запрос на использование периферии, как правило, через шину. конечно, в какой-то мере можно рассматривать команду процу как как запрос на использование CPU, но это не ввод-вывод в юзерском понимании. это исполнение вполне себе линейного сегмента кода, в его самой простой форме. вот что я имею в виду.
а реализованы атомарные операции именно за счёт особенностей конкретного чипа (процессора). без поддержки железа, просто сбоку, их прилепить очень сложно, практически нереально. это архитектура железа.

есть железки у которых нет ОС и нет такого понятия как модуль ядра в принципе

это ты МНЕ рассказываешь? я программировала всё от микрочипов до FPGA, причём на низком уровне. мой отладчик - высокочастотный осциллограф, а документация - доки на железо и схемы ясен пень, что в подавляющем числе случаев никакой оси нет. либо она разрабатывается производителем или сторонней компанией, отдельно от самого контроллера и часто вовсе не бесплатно. смотря какая задача, смотря какой чип, смотря что ты собрался делать. просто часто сам пишешь свой простой загрузчик и подобие мелкого ядра. так удобнее: девайс не должен выходить из строя, должна быть возможность обновления микрокода и юзер должен иметь возможность его прошивать. а кто его будет прошивать? это либо ставить ещё один контроллер (который, опять же, надо программировать!), либо писать загрузчик, который жёстко сидит в защищённой области и уже сам грузит что-то с флэшки. мы делаем когда как: если триггеров в запасе дофига - тогда проще сделать загрузчик. а если ресурс ограничен и конфигурация какая-то сложная, где много DSP-шек на одной плате шьются параллельно - можно и отдельно чип поставить. и вот я пишу то самое программное обеспечение. я программист отдела аппаратного обеспечения

Сообщение отредактировал Iron Bug - 18.11.2011, 12:59

[BRE]

ыхх... сложно говорить с юзерами верхнего уровня!

Это ты про меня?

хардварная атомарность не имеет отношения к вводу-выводу.

Какая хардварная атомарность?
Мы говорим о реализации атомарных операций на пользовательском уровне... Если говорить про архитектуру x86, то они довольно просто реализуются на пользовательском уровне с использованием ассемблера.

Инструкция

mov eax, ebx

а точнее ее опкод, это четкая команда железке под названием процессор загрузить содержимое внутреннего регистра ebx в регистр eax. Это можно рассматривать как обращение к железу!

[Iron Bug]

загрузить содержимое внутреннего регистра ebx в регистр eax

в регистре - дофига битов. и вот именно чтобы их все загрузить "одновременно" (на самом деле, это не так, но синхронизация на шине позволяет получать данные со всех битов сразу) и нужна аппаратная атомарность. а если идёт обмен по шине, например, с памятью? читаем блок данных с DDR или с SATA: это асинхронный процесс передачи некой последовательности битов. и чтобы было понятно, что адрес выставлен и бёрст пошёл, нужна атомарность на хардварном уровне.
а в некоторых классах чипов вообще нет такого понятия, как байт или слово. есть максимальная разрядность шины. и всё.
так что поддержка некоторых атомарных операций там очень важна.

Сообщение отредактировал Iron Bug - 18.11.2011, 13:32

[BRE]

загрузить содержимое внутреннего регистра ebx в регистр eax

в регистре - дофига битов. и вот именно чтобы их все загрузить "одновременно" (на самом деле, это не так, но синхронизация на шине позволяет получать данные со всех битов сразу) и нужна аппаратная атомарность.

Хорошо и что это опровергает в моих словах?
Выполнение инструкции процессора это не обращение к железу?
Или это делает невозможным реализацию атомарных операций?
О чем спорим?

[Iron Bug]

О чем спорим?

я не спорю. я просто уточняю понятие атомарности