I/O and Operating Systems Flashcards
I/O controller
Acts as a translator between digital (CPU) and analog (device); consists of three basic parts:
○ electronics (convert device’s inputs into digital data the CPU can understand)
○ status register
○ data register(s)
Status register
hardware register containing information about the state of the I/O device
Data register
stores the data being transferred to and from the I/O device
Isolation
In terms of the OS and I/O discussion, the OS isolates user programs from one another. A given user program should “feel” it owns the hardware but the OS actually owns it. All programs “believe” they own hardware but they are really using it in a time-sharing mode controlled by the OS.
○ Makes programs much easier to write.
○ Makes the whole system more stable and secure.
■ A can’t mess with B if it doesn’t even know B exists!
Polling
one of two techniques for working with I/O devices. Polling refers to requesting status from the I/O devices until there is status to be given. Sort of like a “Mom/Dad, are we there yet? How about now? How about now?” model.
Interrupts
second technique for working with I/O devices. The I/O device sends a signal to the OS (called an “interrupt request”) to give its status. When the OS is ready, it deals with the interrupt (usually by invoking something like a trap).
○ Think of how you set up email on your smartphone: you can have the server send it to you (like the interrupt model) or you can constantly check it for new emails (poll the server)!
Video display
○ Entire display is memory-mapped.
○ One memory location per pixel
○ Memory region xC000-xFDFF
■ xC000-xC07F is first row, xC080-xC0FF is second row, etc.
○ To set pixel color, write to memory location.
Adressing a pixel
○ Pixel at vmem[2][5] stored at ■ xC000 + (2 * 128) + 5 ○ In general vmem[y][x] stored at ■ xC000 + (y * 128) + x ○ Note indexing from upper-left corner of the display
TRAP
○ The TRAP instruction is very similar to a JSR but it also elevates the privilege level of the CPU from 0 to 1.
○ The purpose of the TRAP instruction is to allow a program to run in USER program memory.
○ Because of TRAPs limitation, the user can only jump into the first 256 rows of the OS. We shouldn’t install our “TRAPS” starting at x8000.
RTI
○ The RTI instruction is very similar to a RET:
■ It restores the PC back to the value saved in R7 (just like RET).
■ But it also lowers the privilege level of the CPU from 1 to 0.
○ The purpose of the RTI instruction:
■ Allow a subroutine running in the OS program memory to return back to a caller in the USER program memory.
ASCI HEX for A and a
A = 0x41 a = 0x61
First job of OS
Handle I/O
User program ask OS to perform I/O on their behalf
Why I/O only handled by OS
- Standardization: I/O device interface nasty and may of them, programs shouldn’t have to deal with them
- Abstraction: Wrap nasty physical interfaces withnice logical ones. Wrap disk layout in file system interface
- Enforce isolation: Each program thinks it has the hardware to itself. User programs unaware of the other programs. Makes programs much easier to write. Makes system more stable and secure. A can’t mess with B.
2 schemes to interact with I/O devices
- Polling: Check register in a loop. Inefficient
2. Interrupts: Device sends signal to CPU when status changes. CPU can do something different while nothing to do.
Synchronous / Asynchroous
Interrupt driven i/o is asynchronous, takes unbounded time. To us it looks like I/O is synchronous, i.e. happens immediately
Access Range of TRAP
Only first 256 in OS as TRAP instruction can only take a 8 bit unsigned number.
I/O Controller
Translater between CPU and I/O Device.
I/o controller interface abstracts i/o device as “device registers
LC4 I/O devices
Keyboard (Input)
ASCII console (Ouput
128x124 RGB pixel display (output)
Timer (egg timer)
How can device register reads/writes performed: 2 Approaches
Two options
- create new i/o instruction for isa. not ideal. whenever we add new device, we might need new instruction. might run out of opcodes -> new ISA -> break backward compatability
- Memory mapped I/O
- Assign a memory address to each device register. Use conventional loads and stores
- hardware intercepts loads/stores to these address
- NO ACTUAL MEMORY ACCESS PERFORMED
Data Memory Areas
User Code: 0x0000 - 0x1FFF User Data: 0x2000 - 0x7FFF t.o. Global 0x2000 - 0x3FFF t.o. Heap 0x4000 - 0x6FFF t.o. Stack 0x7000 - 0x7FFF OS Code: 0x8000 - 0x9FFF OS Data 0xA000 - 0xBFFF Device Memory: 0xC0000 - 0xFFFF t.o. xC000 -xFDFF Video to. XFE0 - device registers
Steps read in from keyboard
- User presses “A”
- electronics box puts a in Data Register
- electronics box changes status register to 1
- Programmer checks Status Register
- If MSB = 1, programmer reads data register
- electronics box reets status register after read
Assembly Code for Reading from Keyboard
GETC
LC R0, OS_KBSR_ADDR; load address of keyboard into staus register
LDR R0,R0, #0 ; set R0 equal to value of status register
BRzp GETC ; if MSB, i.e. R0[15] not 1 keep polling. MSB = 1 –> negative number
LC R0, OS_KBDR_ADDR; Load addres of data register
LDR R0, R0, #0 load data in
Difference .FILL .UCONST
Fill appears in Data memory
.UCONST not , Just a label for a unsigned number
LC vs LEA
LC = loads value at the label LEA = Loads address of the label
Whats wrong with this code? how to fix it .CODE .ADDR 0x0000 GETC LC R0, OS_KBSR_ADDR LDR R0,R0, #0
LDR will fail, we do not have the right to access the address of KBSR as it is in OS and we are in user code with PSR[15]=0;
--> Issue with below. how can we jump here via subroutine from user Code. we have PSR[15]=0; .OS .CODE .ADDR 0x8000 GETC LC R0, OS_KBSR_ADDR LDR R0,R0, #0
Solution use trap. that can access first 256 address in OS and make trap jump from there to effective SR in OS
Solution
TRAP x00, stores R7 = PC+1, sets PSR[15] = 1 and PC = x8000 | x00
.OS
.CODE
.ADDR 0x8000
JMP TRAP_GETC ; x00
TRAP_GETC
LC R0, OS_KBSR_ADDR
LDR R0,R0, #0
TRAP Vector table
Reference table beginning of OS routing incoming TRAP calls to the respective subroutine in OS
TRAP & Register Files
Register Files used by TRAP too. Might not be the same after returning from TRAP
Hence, make a backup of REG files before you call a TRAP, and restore it afterward
Ways to pass in arguments to TRAPS
Register Files
Data Memory, pass starting address in data memory to the TRAP
Can you call a TARP from another trap
No because:
a) By calling another TRAP you overwrite your original return address in R7
b) when you return from the TRAP you called within the TRAP, RTI will set PSR[15]=0 and you cannot access anymore the TRAP you came from
Device Register
is the view any device presents to a programmer. Each programmable bit in the device is presented with a logical address and it appears as a part of a byte in it
The most important advantage of doing I/O through a trap routine is that it is not necessary for the programmer to know the gory low-level details of the data register and status register and other hardware mechanisms.
True
The details may change from computer to computer for hardware I/O, using a trap routine requires no hardware-specific knowledge on part of the programmer and save time.
I/O Traps
- Call TRAPS in main program, RA stored in R7, MSB of PSR Elevated to 1
- At the beginning of OS in TRAP TABLE section, position respective JMP instruction to the respective routine
e.g. JMP TRAP_PUTC
–> JMP and not JSR, a) we do not want to return to beginning of OS, b) JSR would overwrite R7 that brings us back to main program
JMP does not require .FALIGN - Check Limits of Inputs, if required
- Poll Over SR
- write to or get data from DR
- RTI, PSR MSB reset to 0
