информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыSpanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Logitech готовится закрыть очередную... 
 Серьёзная атака на инфраструктуру... 
 Microsoft призналась в сознательном... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
out / in 25.07.03 10:43  Число просмотров: 800
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 25.07.03 10:59  Количество правок: 2
<"чистая" ссылка>
> Я тут столкнулся с одной проблемкой ...
> Допустим некоторое устройство занимает диапазон адресов на
> шине 0х1000 - 0х100F.
> Если теперь обратиться к порту
>
> mov dx, 0x1000
> mov ax, 0x4321
> out dx, ax
>
> Вопросы:
> а) будет ли значение 0х43 записано в порт 0х1001, а
> значение 0х21 - в порт 0х1000

Нет, не факт, зависит от реализации.

> б) или же в зависимости от разрядности шины 8/16/32
> (ISA/PCI) (плюс реализация конкретного контролллера
> (устройства на шине)) значение 0х4321 будет записано
> "полностью" только в порт 0х1000 при условии , если шина
> "не 8 разрядная" и контроллер "воспринимает" конкретно под
> данному адресу 16 битные аргументы.

При желании можно сделать и так, и так. Как, впрочем на ХТ и на 286АТ и было. ISA шинку я в свое время хорошо исследовал. Посмотрим на сигналы 24 адреса, 16 данных, MemRead, MemWrite, IORead, IOWrite, признак 16 разрадности данных (out port, AX или out port, AL)... Это для АТ. На ХТ (8-бит ISA) 20 адреса, 8 данных, отсутствует признак 16 разрядности данных.
Короче - паяем плату - ставим дешифратор адреса (обычно на старшие разряды без младших 4 бит) - это признак, что обратились к нашему устройству, младшие биты дешифрируем на регистр устройства. Далее можем реагировать даже на обращение к памяти, но лучше подключаемся к сигналам управления I/O. Можем на старшие 8 бит данных вообще плевать (даже не припаяться), как это будут делать ХТшные платы в АТ-16-ISA шине. Можем закинуть старшие 8 бит слова данных в следующий 8-битный регистр. Можем при обращении по нечетному адресу младшие биты закинуть в старшие разряды предыдущего 16-разрядного регистра, а старшие (если данные 16 разрядные) в младшие биты следующего регистра. Так обычно не делают, поскольку сложно для портов. Для ПЗУ/ОЗУ - не так уж и сложно. Поэтому с видео ОЗУ/ПЗУ - делай, что хочешь (8/16 по любому адресу). С портами сложнее - поэтому для IDE - только 16-битными словами, COM, LPT - 8-битными.

Еще раз - с портами (когда паяют микросхемы - регистры не в зависимости 8 или 16 разрядные) на каждый адрес - своя микросхема на дешифрацию адреса реагирует. Хотя были разные реализации. Пример (один только) вспоминается: в VGA видео адаптере есть такие регистрики (3c4/3c5, 3b4/3b5 или 3d4/3d5 для цветного VGA) первый - адрес 8-битного регистра, второй - данные. Читать данные приходится последовательно однозначно, поскольку сначала запись номера регистра в первый порт, потом чтение из второго. А вот писать данные в регистрики можно было и за раз 16 битным обращением - младшие 8 бит адрес регистра, старшие - данные. Были адаптеры, на которых это работало. Хотя могли быть такие, на которых это и не сработало бы.
Чипсет - тоже великая вещь. На ХТ в порт тоже 16 разряд можно было закинуть. Там чипсет соответственно выставлял адрес, кидал младшие 8 бит по данным, затем адрес увеличивал на 1 и кидал старшие разряды. Стало быть на ХТ старшие биты всегда по следующему адресу пойдут. На АТ так уже нельзя - чипсет другой и IDE тому подтверждение.

Можете поэксперементировать со своими портами, чтобы точно узнать.

> в) будет ли происходить тоже самое при
>
> out dx, eax
>
> т.е. при 32 разрядном аргументе
>
> г) Верно ли "обратное" ,- при чтении (in) из порта.
>
> PS: Поскольку я не технарь по-образованию, надеюсь, вы мне
> простите "такой" вопрос ;)

Попробуйте на LPT или COM порте. Скорее всего только младшие 8 бит пройдут. PCI шина вообще хитрая вещь. Сам, не пробовал.
<programming>
out / in 24.07.03 20:22  
Автор: oleaster Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я тут столкнулся с одной проблемкой ...
Допустим некоторое устройство занимает диапазон адресов на шине 0х1000 - 0х100F.
Если теперь обратиться к порту

mov dx, 0x1000
mov ax, 0x4321
out dx, ax

Вопросы:
а) будет ли значение 0х43 записано в порт 0х1001, а значение 0х21 - в порт 0х1000

б) или же в зависимости от разрядности шины 8/16/32 (ISA/PCI) (плюс реализация конкретного контролллера (устройства на шине)) значение 0х4321 будет записано "полностью" только в порт 0х1000 при условии , если шина "не 8 разрядная" и контроллер "воспринимает" конкретно под данному адресу 16 битные аргументы.

в) будет ли происходить тоже самое при

out dx, eax

т.е. при 32 разрядном аргументе

г) Верно ли "обратное" ,- при чтении (in) из порта.

PS: Поскольку я не технарь по-образованию, надеюсь, вы мне простите "такой" вопрос ;)
out / in 25.07.03 10:43  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 25.07.03 10:59  Количество правок: 2
<"чистая" ссылка>
> Я тут столкнулся с одной проблемкой ...
> Допустим некоторое устройство занимает диапазон адресов на
> шине 0х1000 - 0х100F.
> Если теперь обратиться к порту
>
> mov dx, 0x1000
> mov ax, 0x4321
> out dx, ax
>
> Вопросы:
> а) будет ли значение 0х43 записано в порт 0х1001, а
> значение 0х21 - в порт 0х1000

Нет, не факт, зависит от реализации.

> б) или же в зависимости от разрядности шины 8/16/32
> (ISA/PCI) (плюс реализация конкретного контролллера
> (устройства на шине)) значение 0х4321 будет записано
> "полностью" только в порт 0х1000 при условии , если шина
> "не 8 разрядная" и контроллер "воспринимает" конкретно под
> данному адресу 16 битные аргументы.

При желании можно сделать и так, и так. Как, впрочем на ХТ и на 286АТ и было. ISA шинку я в свое время хорошо исследовал. Посмотрим на сигналы 24 адреса, 16 данных, MemRead, MemWrite, IORead, IOWrite, признак 16 разрадности данных (out port, AX или out port, AL)... Это для АТ. На ХТ (8-бит ISA) 20 адреса, 8 данных, отсутствует признак 16 разрядности данных.
Короче - паяем плату - ставим дешифратор адреса (обычно на старшие разряды без младших 4 бит) - это признак, что обратились к нашему устройству, младшие биты дешифрируем на регистр устройства. Далее можем реагировать даже на обращение к памяти, но лучше подключаемся к сигналам управления I/O. Можем на старшие 8 бит данных вообще плевать (даже не припаяться), как это будут делать ХТшные платы в АТ-16-ISA шине. Можем закинуть старшие 8 бит слова данных в следующий 8-битный регистр. Можем при обращении по нечетному адресу младшие биты закинуть в старшие разряды предыдущего 16-разрядного регистра, а старшие (если данные 16 разрядные) в младшие биты следующего регистра. Так обычно не делают, поскольку сложно для портов. Для ПЗУ/ОЗУ - не так уж и сложно. Поэтому с видео ОЗУ/ПЗУ - делай, что хочешь (8/16 по любому адресу). С портами сложнее - поэтому для IDE - только 16-битными словами, COM, LPT - 8-битными.

Еще раз - с портами (когда паяют микросхемы - регистры не в зависимости 8 или 16 разрядные) на каждый адрес - своя микросхема на дешифрацию адреса реагирует. Хотя были разные реализации. Пример (один только) вспоминается: в VGA видео адаптере есть такие регистрики (3c4/3c5, 3b4/3b5 или 3d4/3d5 для цветного VGA) первый - адрес 8-битного регистра, второй - данные. Читать данные приходится последовательно однозначно, поскольку сначала запись номера регистра в первый порт, потом чтение из второго. А вот писать данные в регистрики можно было и за раз 16 битным обращением - младшие 8 бит адрес регистра, старшие - данные. Были адаптеры, на которых это работало. Хотя могли быть такие, на которых это и не сработало бы.
Чипсет - тоже великая вещь. На ХТ в порт тоже 16 разряд можно было закинуть. Там чипсет соответственно выставлял адрес, кидал младшие 8 бит по данным, затем адрес увеличивал на 1 и кидал старшие разряды. Стало быть на ХТ старшие биты всегда по следующему адресу пойдут. На АТ так уже нельзя - чипсет другой и IDE тому подтверждение.

Можете поэксперементировать со своими портами, чтобы точно узнать.

> в) будет ли происходить тоже самое при
>
> out dx, eax
>
> т.е. при 32 разрядном аргументе
>
> г) Верно ли "обратное" ,- при чтении (in) из порта.
>
> PS: Поскольку я не технарь по-образованию, надеюсь, вы мне
> простите "такой" вопрос ;)

Попробуйте на LPT или COM порте. Скорее всего только младшие 8 бит пройдут. PCI шина вообще хитрая вещь. Сам, не пробовал.
out / in 24.07.03 22:52  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> Я тут столкнулся с одной проблемкой ...
> Допустим некоторое устройство занимает диапазон адресов на
> шине 0х1000 - 0х100F.
> Если теперь обратиться к порту
>
> mov dx, 0x1000
> mov ax, 0x4321
> out dx, ax
>
> Вопросы:
> а) будет ли значение 0х43 записано в порт 0х1001, а
> значение 0х21 - в порт 0х1000

да

> б) или же в зависимости от разрядности шины 8/16/32
> (ISA/PCI) (плюс реализация конкретного контролллера
> (устройства на шине)) значение 0х4321 будет записано
> "полностью" только в порт 0х1000 при условии , если шина
> "не 8 разрядная" и контроллер "воспринимает" конкретно под
> данному адресу 16 битные аргументы.

Нет, от разрядности шины это не зависит. В x86 у I/O портов единое адресное пространство, и не имеет значения, как ты к нему будешь обращаться - через 8/16 или 32-разрядные порты.

> в) будет ли происходить тоже самое при
>
> out dx, eax
>
> т.е. при 32 разрядном аргументе

да

> г) Верно ли "обратное" ,- при чтении (in) из порта.

да

> PS: Поскольку я не технарь по-образованию, надеюсь, вы мне
> простите "такой" вопрос ;)
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach