// Пример: Обращение к диску напрямую через окно перекрытия.
// Контроллер HDD, как и видеокарта, имеет свою память, которая
// проецируется в общем линейном адресном пространстве.
typedef struct {
char buffer[65536]; // Собственно, кэш буффера-зеркало диска
long seek_position; // Указатель линейного пространства диска
long flush_command; // Регистр управления
} *HDDC; // Структура контроллера в линейной памяти
int main() {
HDDC hDisk;
hDisk = GetDirectHDD(); // Запрашиваем у OS адрес HDD-контроллера
hDisk->seek_position = 0; // Будем читать BOOT-SECTOR
hDisk->flush_command = HDDC_READ; // Посылаем команду чтения
hDisk->buffer[0x002] = 0x90; // Пишем команду NOP
hDisk->flush_command = HDDC_WRITE; // Посылаем команду записи
} // Тем самым, минуя OS-API мы работали с внутренней памятью
// контроллера HDD как с поверхностью диска
IBM PC-NT
Все контроллеры дисков, ПДП, IRQ, порты - начали формироваться ещё в 80-ых с приходом PC-XT. Тогда "интеллект" контроллеров был на уровне начинки мышки и ниже. Сейчас дело то другое, всё изменилось.
Допустим, обновляем весь PC и всё строим с нуля на современной базе. Вместо портов HDD - страница памяти и новый протокол. И т.д.
При необходимости "новые" контроллеры опционально могут эмулировать традиционные порты. Но, в современных OS - только новый уровень! Доступ к портам, к тому же, самая медленная и ограниченная часть x86...
Допустим, обновляем весь PC и всё строим с нуля на современной базе. Вместо портов HDD - страница памяти и новый протокол. И т.д.
При необходимости "новые" контроллеры опционально могут эмулировать традиционные порты. Но, в современных OS - только новый уровень! Доступ к портам, к тому же, самая медленная и ограниченная часть x86...
Цитата:
Доступ к портам, к тому же, самая медленная и ограниченная часть x86...
Да медленная. Но вначале надо разобраться почему она медленная. И как с этим борятся.
Цитата:
Допустим, обновляем весь PC и всё строим с нуля на современной базе. Вместо портов HDD - страница памяти и новый протокол. И т.д.
Давно пора почуствуй настоящие ускорение. Такии компы уже давно у всех стоят. Один ты видать остался! У меня лично такой комп лет пять стоит.
Цитата: Pavia
Да медленная. Но вначале надо разобраться почему она медленная. И как с этим борятся.
Давно пора почуствуй настоящие ускорение. Такии компы уже давно у всех стоят. Один ты видать остался! У меня лично такой комп лет пять стоит.
Давно пора почуствуй настоящие ускорение. Такии компы уже давно у всех стоят. Один ты видать остался! У меня лично такой комп лет пять стоит.
Что-то я в сети не встречал информации, что прямой доступ к диску работает уже без портов, а палитра изменяется не регистрами через порты, а в памяти.
Если я всё проспал, не могли бы дать ссылку на информативный источник? ;й)
Цитата:
Что-то я в сети не встречал информации, что прямой доступ к диску работает уже без портов
Пожалуйста.
http://www.intel.com/technology/serialata/ahci.htm
Цитата:
а палитра изменяется не регистрами через порты, а в памяти.
Вы что палитрой пользуетесь? В мире правит SVGA с TrueColor.
Но ты возьми спецификации видео карт и посмотри там у них у всех идет дублирования регистров в памяти.
"Дублирование" портов в адресное пространство памяти отнюдь не делает обмен с ними более быстрым.
В целом же согласен с Pavia, - прежде, чем пытаться что-либо предложить, неплохо бы ознакомиться с текущим состоянием вопроса. В противном случае самое лучшее, на что можно надеяться, это изобрести велосипед.
В целом же согласен с Pavia, - прежде, чем пытаться что-либо предложить, неплохо бы ознакомиться с текущим состоянием вопроса. В противном случае самое лучшее, на что можно надеяться, это изобрести велосипед.
Цитата: andriano
"Дублирование" портов в адресное пространство памяти отнюдь не делает обмен с ними более быстрым.
Но я же не это имел ввиду!
Извиняюсь...
Например, порты мышки, грубо говоря, отсутствуют. Но, есть пять ячеек памяти: word X, word Y, byte buttons...
Получил прерывание и уже знаешь, готовы новые относительные координаты.
Контроллер HDD - окно памяти и прямое зеркало на кластер. Пишешь туда - контроллер сам копирует данные на диск. Читаешь - читает... Никаких DMA и всяких там портов...
Клавиатура - 16 байт в памяти. В каждом байте - информация о 8-ми клавишах. 1 - нажата, бит 0 - отжата. Прямое зеркало на состояние матрицы клавиатуры...
И так все контроллеры...
Вот о чём я. Товарищи! :)
Цитата:
Контроллер HDD - окно памяти и прямое зеркало на кластер. Пишешь туда - контроллер сам копирует данные на диск. Читаешь - читает... Никаких DMA и всяких там портов...
Операция ввода вывода очень медленная. Поэтому такая система будет тормозить. Для этого используют систему прерываний и DMA.
Рассказываю как работает на данный момент.
В далеком 1981 была разработана шина ISA. С тех пор она была несколько раз усовершенствована.
А после вытиснена шиной PCI.
1992 год появилась шина PCI 1.0
1993 год появилась шина PCI 2.0
1995 год появилась шина PCI 2.1
Так вот в 1994 году был разработан PCI IDE контроллер для работы с жестким диском. Основным отличием от ISA IDE было? то что он был снабжен технологией захвата шины Bus Master. Bus Master это особенность шины PCI теперь устройство само может захватывать шину и инициировать циклы передачи приема данных и для этого не требуется на каждый чих реагировать процессору. Тем самым каждое устройство PCI может напрямую, минуя процессор, обращаться к памяти компьютера. Но как известно память компьютера работает последовательно. Так работают почти все шины. Поэтому процессор выступает в качестве руководителя который выдает задания. Если бы все устройства постоянно опрашивали бы память, то компьютер бы просто бы завис. Поэтому активацию и или планирование осуществляет процессор. Он выдает команду устройству и оно начинает выполнять.
Почему не отвести в устройстве участок памяти и не делать запись в этот участок? Ответ очень прост. Дело в том что во первых шина PCI медленнее процессора и медленнее чем частота шины памяти. Но это не все для передачи байта нужно согласовать передачу. Сделать так называемое рукопожатие.
Рассмотрим на примере. Нам нужно передать байт данных.
Для этого процессор должен подать сигнал старт убедиться что он дошел до устройства получить ответ что привет дошел отправить команду передачи данных проверить ответ что принимающий получил этот сигнал. И только после отправить данные. Получить ответ о достижении данных в целостности. Разорвать соединение.
Теперь рассмотрим чтение. Тут все тоже самое.
Для этого процессор должен подать сигнал старт убедиться что он дошел до устройства получить ответ что привет дошел отправить команду приема данных проверить ответ что принимающий получил этот сигнал. Отправить адрес который мы хотим прочитать. Проверить что устройство его получило. Дождаться пока устройство будет готово передавать данные. принять данные доложить о приеме в целостности. Разорвать соединение.
Так вот на такое рукопожатие приходиться уйма времени. Поэтому передавать байтами не выгодно. Так как на один байт приходится еще до 5 служебных, а то и больше. Поэтому все шины работают на блочной передачи данных. За раз передается не один байт данных, а несколько.
Вернемся к PCI IDE который появился в 1994 году. Так вот его регистры BUS Master отоброжены в память компьютера. Программирование видится следующем образом.
В основной памяти компьютера создается список. Из указателей в котором указанно размер и адрес откуда нужно читать или писать данных.
Компьютер через порты ввода вывода сообщает что нужно считать данные и записать их используя DMA, а именно через Bus Master. Теперь передачью управляет контроллер диска. Он сам читает список и смотрит по какому адресу надо записать или считать данные.
Тем самым контроллер не опрашивает все время память на наличие данных. И не ждет пока запишут один байт, так как это медленно. А тихо и мирно ждет пока ему не скажут откуда читать или писать и сколько байт.
В 2003 году появились SATA диски. В отличии от классических PATA уменьшилось число проводов. Но главное это то что на одном шлейфе сидит один контроллер.
Это позволяет распаралелить обращение к дискам.
В 2004 году появился первый AHCI контроллер. Все команды к нему идут через память. Но выигрыша это не дает. Основное преимущество в том что мы можем параллельно посылать команды разным винчестером.
В 1996 году появилась шина USB 1.0. С этих пор клавиатура и мышь которые являются HID устройствами передают результат в память компьютера. Как только пришло прерывание результаты известны. а формат именно такой который ты описал.
И это было лет 10 назад.
Хотя никакой разницы откуда читать данные из памяти или из портов нет. USB также может эмулировать порты для этих устройств.
В 1994 появился первый процессор с APIC на борту. APIC расширенный контроллер прерываний. Программирование идет через память.
Vertecs Итог это все есть уже лет 10.
Цитата: Pavia
Vertecs Итог это все есть уже лет 10.
Спасибо за просвещение! ;)
Ужас! Я будто из средних веков вылез и многого не знаю...
Скажите, а что по поводу:
Видеокарта сама может взаимодействовать с несколькими задачами сразу, не прерывая исключениями для перезагрузки контекста систему. Так, если разные прикладные задачи обращаются к одному ресурсу, видеокарта сама распознаёт и переключает контекст. В сложных же случаях - прерывает систему.
Пример кривой, но суть думаю ясна...
Может не с видеокартами, а с другими девайсами такое есть?
Как-то ты непонятно написал. Что нужно-то?
Во первых. Надо понимать что ЦП - центральный процессор и ему должны подчиняться все другие устройства. Никак не наоборот, а то получится революция, а они как известно из истории ничем кроме войны и крови не кончаются.
Собственно поэтому видео кара не может менять контекст ЦП.
Сама по себе видео карта ни с чем таким не взаимодействует кроме памяти компьютера. А вот ЦП ей управляет. Но управление это хитрое. Все сводиться к тому что есть буфер в который заноситься программа для видео карты и она ее начинает выполнять по кругу.
Так вот видео карта взаимодействует не с задачей, а с физической памятью.
Если у тебя в памяти находятся несколько задач, то она может работать с объектами из разных задач.
Видео карта выполняет две вещи это пересылка данных. И расчеты. Никакими управлением она не занимается. Еще она может вызывать прерывания.
А когда процессору приходит прерывание он уже и решает что делать может и контекст переключить.
А вот что интересно.
Теоретически возможно следующее мы можем написать программу для видео карты, которая будет работать напрямую с жеским диском минуя процессор.
Во первых. Надо понимать что ЦП - центральный процессор и ему должны подчиняться все другие устройства. Никак не наоборот, а то получится революция, а они как известно из истории ничем кроме войны и крови не кончаются.
Собственно поэтому видео кара не может менять контекст ЦП.
Сама по себе видео карта ни с чем таким не взаимодействует кроме памяти компьютера. А вот ЦП ей управляет. Но управление это хитрое. Все сводиться к тому что есть буфер в который заноситься программа для видео карты и она ее начинает выполнять по кругу.
Так вот видео карта взаимодействует не с задачей, а с физической памятью.
Если у тебя в памяти находятся несколько задач, то она может работать с объектами из разных задач.
Видео карта выполняет две вещи это пересылка данных. И расчеты. Никакими управлением она не занимается. Еще она может вызывать прерывания.
А когда процессору приходит прерывание он уже и решает что делать может и контекст переключить.
А вот что интересно.
Теоретически возможно следующее мы можем написать программу для видео карты, которая будет работать напрямую с жеским диском минуя процессор.
Цитата: Pavia
Как-то ты непонятно написал. Что нужно-то?
Вот в оконных приложениях используются GDI, DDRAW и пр. муть...
А нельзя ли всю видеопамять организовать так, чтобы видеокадр в пикселах хранил не информацию о цвете, а адрес?
Разъясню. Каждому оконному приложению система выделяет свой фрейм видеопамяти. По типу перекрытия. А в главном видеобуфере пиксели лишь заполняются индексами буфферов перекрытия.
Т.е. тупо перетаскиваем одно окно поверх другого, а система лишь перерисовывает красный прямоугольник поверх зелёного, например. Тогда как приложения минуя библиотеки напрямую рисуют свой интерфейс прямо в буфферах перекрытия.
Скажем, видреопамять основного кадра может вывести лишь пиксели 8-битные, т.е. 256 цветов палитры. Но, каждый элемент таблицы палитры - не байты цвета, а целый указатель на приложение, начало буффера перекрытия и размер, режим пикселей в буфере, смещение относительно экрана и т.д...
Это напоминает систему спрайтов в Dendy/Sega видеочипов. Понимаю, это дорого и максимум наверно сейчас можно достигнуть лишь до 16 буферов. Но, теоритически, я думаю, к этому должно прийти. Десятки программ одновременно рисуют 3D в окнах минуя программный OpenGL напрямую через структуры своих буфферов перекрытия...
Система лишь следит и поправляет...
Сделать скорее всего можно. Но не эффективно. Да и смысла в этом нету. Лучше в общий котел.
С масками лучше не вазиться, а воспользоваться Z-буффером или просто вручную выводить в нужном порядке.
С масками лучше не вазиться, а воспользоваться Z-буффером или просто вручную выводить в нужном порядке.
Цитата: Pavia
Сделать скорее всего можно. Но не эффективно. Да и смысла в этом нету. Лучше в общий котел.
С масками лучше не вазиться, а воспользоваться Z-буффером или просто вручную выводить в нужном порядке.
С масками лучше не вазиться, а воспользоваться Z-буффером или просто вручную выводить в нужном порядке.
Тут я хотел бы поправить. Альтернативный вариант.
Для всех приложений доступно линейное графическое окно с 0xA0000000. Но, когда система передаёт управление оконному приложению, она придупреждает контроллер, переключая контекст. Там прописано, где начинается прямоугольник окна, его размеры и т.п.
Приложение пишет точку по адресу 0xA0000000, а контроллер сам корректирует адрес, смотрит, записан ли там код этого приложения? Если нет, точка не пишется никуда. Если да, вычисляется физический адрес (Client_position) в общем буфере экрана и точка пишется туда...
Короче, не система проверяет перекрывается ли область окна другими, а аппаратура видяхи. Для всех приложений поверхность их окна отражается в одном и том же сегменте, но физически доступ перенаправляется на разные области реального буфера кадра. Это как GetDC(hWin) для приложения, или GetDC(0) для общего кадра.
Подобно как несколько DOS-приложений все пишут графику в сегмент 0xA0000, но VDM выводит её в разных окнах общего экрана. Но, видяха без участия процессора сама перенапрявляет и преобразовывает логическую позицию пикселей в физическую..........
На счёт диска. Коротко, всё работает примерно так?
Код: