crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Мьютексы
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Iron Bug Дата 18.11.2011, 14:00
 
Цитата(BRE @ 18.11.2011, 16:40) *
О чем спорим?

я не спорю. я просто уточняю понятие атомарности :)
BRE Дата 18.11.2011, 13:40
 
Цитата(Iron Bug @ 18.11.2011, 14:26) *
Цитата(BRE @ 18.11.2011, 16:21) *
загрузить содержимое внутреннего регистра ebx в регистр eax

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

Хорошо и что это опровергает в моих словах? :)
Выполнение инструкции процессора это не обращение к железу?
Или это делает невозможным реализацию атомарных операций?
О чем спорим? :)
Iron Bug Дата 18.11.2011, 13:26
 
Цитата(BRE @ 18.11.2011, 16:21) *
загрузить содержимое внутреннего регистра ebx в регистр eax

в регистре - дофига битов. и вот именно чтобы их все загрузить "одновременно" (на самом деле, это не так, но синхронизация на шине позволяет получать данные со всех битов сразу) и нужна аппаратная атомарность. а если идёт обмен по шине, например, с памятью? читаем блок данных с DDR или с SATA: это асинхронный процесс передачи некой последовательности битов. и чтобы было понятно, что адрес выставлен и бёрст пошёл, нужна атомарность на хардварном уровне.
а в некоторых классах чипов вообще нет такого понятия, как байт или слово. есть максимальная разрядность шины. и всё.
так что поддержка некоторых атомарных операций там очень важна.
BRE Дата 18.11.2011, 13:21
 
Цитата(Iron Bug @ 18.11.2011, 13:57) *
ыхх... сложно говорить с юзерами верхнего уровня! :)

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

Цитата(Iron Bug @ 18.11.2011, 13:57) *
хардварная атомарность не имеет отношения к вводу-выводу.

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

Инструкция
mov eax, ebx

а точнее ее опкод, это четкая команда железке под названием процессор загрузить содержимое внутреннего регистра ebx в регистр eax. Это можно рассматривать как обращение к железу! :)
Iron Bug Дата 18.11.2011, 12:57
 
Цитата(BRE @ 18.11.2011, 15:38) *
Это ты начала

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

Цитата(BRE @ 18.11.2011, 15:38) *
есть железки у которых нет ОС и нет такого понятия как модуль ядра в принципе

это ты МНЕ рассказываешь? :D я программировала всё от микрочипов до FPGA, причём на низком уровне. мой отладчик - высокочастотный осциллограф, а документация - доки на железо и схемы :) ясен пень, что в подавляющем числе случаев никакой оси нет. либо она разрабатывается производителем или сторонней компанией, отдельно от самого контроллера и часто вовсе не бесплатно. смотря какая задача, смотря какой чип, смотря что ты собрался делать. просто часто сам пишешь свой простой загрузчик и подобие мелкого ядра. так удобнее: девайс не должен выходить из строя, должна быть возможность обновления микрокода и юзер должен иметь возможность его прошивать. а кто его будет прошивать? это либо ставить ещё один контроллер (который, опять же, надо программировать!), либо писать загрузчик, который жёстко сидит в защищённой области и уже сам грузит что-то с флэшки. мы делаем когда как: если триггеров в запасе дофига - тогда проще сделать загрузчик. а если ресурс ограничен и конфигурация какая-то сложная, где много DSP-шек на одной плате шьются параллельно - можно и отдельно чип поставить. и вот я пишу то самое программное обеспечение. я программист отдела аппаратного обеспечения :)
BRE Дата 18.11.2011, 12:38
 
Цитата(Iron Bug @ 18.11.2011, 13:16) *
атомарность - не обращение к железу.

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

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

Цитата(Iron Bug @ 18.11.2011, 13:16) *
ну да. просто я имею в виду без оси. биос поставляет производитель железа, это не относится к оси. без него вообще ничего не будет работать: только выдирать флэшку и перепрошивать программатором :)

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

Цитата(Iron Bug @ 18.11.2011, 13:16) *
смысл-то был в том, что юзер в принципе не должен управлять железом. а если он очень хочет, то нужно писать сначала драйвер кернел мода(в этой области я уже не умею говорить по-русски :) ), потом, возможно, драйвер юзерского уровня - для повышения эффективности использования и программирования политик и интерфейсов. и уже потом юзать вызовы своего драйвера верхнего уровня.

Это ты говоришь про то как это устроено в массовом секторе, но есть железки у которых нет ОС и нет такого понятия как модуль ядра в принципе.
Для таких железок тоже пишут программное обеспечение. :)
Iron Bug Дата 18.11.2011, 12:16
  атомарность - не обращение к железу. вообще, ассемблер - это просто протокол общения с процом. некоторые возможности открыты для юзера. когда речь не идёт о вводе-выводе.

Цитата(BRE @ 18.11.2011, 14:55) *
это делает BIOS.

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

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

это уже глубокий хардварный оффтоп :)
BRE Дата 18.11.2011, 11:55
 
Цитата(Iron Bug @ 18.11.2011, 12:23) *
последняя такая система на моей памяти была Windows 98: она позволяла получить доступ к портам. более современные системы НЕ ПОЗВОЛЯЮТ юзеру работать напрямую с железом никоим образом. потому что это просто нарушит работу системы и безопасность.

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

Цитата(Iron Bug @ 18.11.2011, 12:23) *
железо постоянно меняется. причём очень быстро. даже системные программисты не имеют дел непосредственно с железом. на то есть специальные системные вызовы. иначе был бы полный капец разработке: учитывать особенности каждой конфигурации железа и все изменения протоколов по всем устройствам просто нереально. система для того и существует, чтобы избавлять юзера от всего этого геморроя.

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

Цитата(Iron Bug @ 18.11.2011, 12:23) *
конечно, можно снести систему. и работать с железом.

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

Цитата(Iron Bug @ 18.11.2011, 12:23) *
а комп без софта умеет только грузить бутрекорд на старте и больше нихрена

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

Iron Bug Дата 18.11.2011, 11:23
 
Цитата(BRE @ 18.11.2011, 13:56) *
Цитата(Iron Bug @ 18.11.2011, 11:45) *
просто юзер не может напрямую юзать аппаратные средства. доступ к некоторым реализован через системные интерфейсы и юзерские API. поэтому для программиста верхнего (по сравнению с системным) уровня аппаратных средств, как таковых, не существует. есть только системные.

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

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

Если выбросить ОС, то системных средств у программиста не останется, а аппаратные будут все еще доступны. :)
С помощью ассемблера программист верхнего уровня может получить доступ к определенным аппаратным средствам. Сделать все те же атомарные операции.
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.3.2024, 0:00