Урок №5 Текст I

Feature	Черта, характеристика
Acquisition	Приобретение, сбор
To allow	Позволять
To implement	Воплощать, реализовывать, вводить
Implementation	_______________________________
To insert	Вводить, вставлять
Insertion	_______________________________
Exception	Исключение
Exceptionally	_______________________________
To terminate	Завершать (цикл), выходить (из цикла)
Terminal	_______________________________
Terminating	_______________________________
To debug	Налаживать, отлаживать, устранять (неполадки)
Debugging	_______________________________
Bug	Ошибка, дефект, помеха
Buggy	_______________________________
To attempt	Пытаться, пробовать, делать попытку
Attempt	_______________________________
To restrict	Ограничивать
Unrestricted	_______________________________
Interrupt	Прерывать, прерывание
Trash	Хлам, мусор, отбросы
To trash	_______________________________
Intention	Намерение
Unintentionally	_______________________________
Via	Через
To trust	Доверять(ся), полагать(ся0
Trusted	Проверенный
Piece	Кусок, участок
Entire	Целый, весь
Blessing	Благо, благословение
Curse	Проклятие, ругательство, бич
Generally	В целом
To shake	Трясти(сь), поколебать
Adversely	Враждебно, неблагоприятно, вредно
Adverse	_______________________________
To prevent	Препятствовать, предотвращать
Sprinkling	Разбрасывающий
To verify	Контролировать
To consume	Контролировать, проверять, сличать
Consuming	Потреблять
Costly time-consuming	Дорогостоящий по затратам времени

Задание №1. Просмотрите Текст, подчеркните и отметьте цифрами перевод данных сочетаний, которые могут использоваться в профессиональном разговоре:

1. позволяют вам читать из или записывать в

2. вы не получаете исключения

3. работать таким (подобным) образом

4. (это) было бы слишком рискованно позволить

5. вся системная память

6. с одной стороны

7. с другой стороны

8. целый (весь) день напролет

9. без неблагоприятного воздействия одного на другое

10. предохраняет (оберегает) вас от

11. относительно большое количество времени

12. когда бы вы ни захотели (сделать что-то)

13. это может занять

14. зачем вам вообще нужно (делать что-то)

15. это могло бы облегчить дело

16. один из моих любимых

17. чтобы сделать это, вам нужно установить

18. приемлемый (принятый) способ достигнуть этого

19. быстрый просмотр (через)

20. это было бесполезно для

21. мне нужен был лучший способ

Задание №2. Просмотрите Текст и определите, какой из планов ему соответствует. Планы сначала переведите:

I. Possibilities of port I/O instructions. The way NT is supposed to work. The restriction on I/O port access. The way to put I/O instructions. An accepted way to achieve direct, user-mode port I/O in NT.

II. Debugging the offending applications The NT architects. Exceptionally stable NT. Writing a device driver. Using PORTIO.

Direct Port I/O and Windows NT

Undocumented features fo direct control of hardware devices.

By Dale Roberts. Dale works with data acquisition and con trol software at the Vestibu lar Laboratory of the Johns Hopkins University School of Medicine. He can be reached at roberts@ishtar.med.jhu.edu.

Port 1/0 instructions allow all 80x86 CPUs to commu­nicate with other hardware devices in the system. For low-level, direct control of a hardware device, the С functions _inp() and _out() (implemented using the 80x86 processor's IN arid OUT instructions let you read from or write to and I/O port. However, inserting _inp () or _out() in a Windows NT application gives you a privi­leged-instruction exception message and the option of terminating or debugging the offending app. If you at­tempt port I/O from a 16-bit DOS app in an NT console window, the I/O is either ignored or emulated by NT's virtual device drivers -you don't get an exception.

But you don't get the direct I/O either.

This isn't a bug, NT is supposed to work this way. The NT architects decided that it would be too risky to allow applications to directly access the system hard­ware. With unrestricted I/O access an application could turn off all interrupts, take over the system, and trash the display or the hard drive. A buggy program could unintentionally do the same. NT's architecture requires that all hardware be accessed via kernel-mode device drivers - special, trusted pieces of software that essentially become part of the operating system when loaded. These device drivers have complete access to entire system memory a11 hardware devices, and all privileged processor instructions. In contrast, ap­plications run in user mode, where they have restrict­ed access to memory - and where the' CPU can't execute certain privileged operating-system instructions, in­cluding I/O instructions.!

The restriction on I/O port access is both a blessing and a curse. .On one hand, it makes NT exceptionally stable. Generally, application programmers can write and crash and debug programs all day long without shak­ing NT. Several applications can run without adversely affecting one another. On the other hand, I/O restrictions prevent you from, communicating directly and quickly with the hardware without taking the relatively large amount of time required for a call to a device driver. Whenever you want to communicate with a device driver, you must seлd a request through NT's I/O subsystem. This can take about 30 clock cycles.

Why would you ever need to put I/O instructions in user mode code? When writing a device driver it might make things easier if you could write a quick program to interact with the device, sprinkling printt()s and getchar()s among port I/O instructions so that you could verify that you are driving the device correctly before you put the code into an actual device driver and chance a system lockup. Or you may want to write a portion of a driver in a user-mode DLL (as with video drivers, for instance) to achieve a desired level of performance. One of my favorite uses of I/O is for using an oscilloscope to debug programs and time sections of code. To do this, you need to set and clear a bit in a digital output port and monitor the voltage on a scope.

Since-direct, user-mode port I/O in NT seems so user ful, you'd think there would be an accepted way to achieve it. A quick look through the sample source code in the Windows NT Device Driver Kit (DDK) reveals a program called «PORTIO». Initially, I thought this would provide direct port I/O from an app. However, PORTIO is merely an example showing how to use Win32 DeviceloControl() calls to kernel-mode device driver, which imple­ments the actual I/O. Using PORTIO, each I/O operation requires a costly, time-consuming call to the device driver. This was useless for my oscilloscope timings. l needed a "better way.