Английский язык для пользователей ПК и программистов - Гольцова Е.В.
ISBN 5-7931-0086-5
Скачать (прямая ссылка):
By Dale Roberts. Dale works with data acquisition and con trol software at the Vestibu Iar Laboratory of the Johns Hopkins University School of Medicine. He can be reached at roberts@ishtar.med.jhu.edu.
Port I/O instructions allow all 80x86 CPUs to communicate with other hardware devices in the system. For low-level, direct control of a hardware device, the C functions _inp() and _out() (implemented using the 80x86 processor's IN and 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 privileged-instruction exception message and the option of terminating or debugging the offending app. If you attempt 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 hardware. 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, all hardware devices, and all privileged processor instructions. In contrast, applications run in user mode, where they have restricted access to memory — and where the CPU can't execute Английский для пользователей ПК
certain privileged operating-system instructions, including 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 shaking 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 send a request through NT's I/O subsystem. This can take about 30 clock cycles.
Why1 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 useful, you'd think there would be ah 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 DeviceloCon-trol() calls to kernel-mode device driver, which implements 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. I needed a better way.
98 Урок З
Упражнение 19. Это упражнение для тренировки «быстрого», просмотрового чтения. Просмотрите параграфы и поставьте их в нужном порядке, обращая внимание на подчеркнутые слова:
(Look through the paragraphs and arrange them in proper order paying attention to the underlined words):
Welcome to the Official Red Hat Linux Getting Started Guide!
A. Inside, you'll find valuable tips which will help you get acquainted with GNOME, your new default desktop environment. You'll also learn the fundamentals of navigating and managing files and directories from the shell prompt, or console. Among the new features of Red Hat Linux 6.1 you'll find the RH PPP Dialer, also called RP3; inside, you'll learn how to use this application to get online quickly and easily.
B. if you count yourself among the many who are discovering Red Hat Linux for the first time, this book is for you!
C. But first, a little background...
D. In short this guide picks up where the Official Red Hat Linux Installation Guide leaves off: helping you understand a bit about your new operating system.
E. At Red Hat, we believe we offer the best Linux distribution on the market. We hope you'll agree that the time and the money you spent to install and work with Red Hat Linux was well spent, indeed. Грамматика
