Harvard Architecture & Operating Systems Concepts

Lecture 13 Harvard architecture Coccone OS demonstrator Computing platforms Novosibirsk State University University of Hertfordshire D. Irtegov, A.Shafarenko 2018

Harvard version of CdM-8 Harvard architecture = separate memory banks for data and instruction Can be implemented as: One-bit address extension selecting code and data access (cheap and simple) Separate memory channels (buses) expensive but boosts performance Memory buses of different width (example: Microchip PIC has 8-bit data and 14-bit instruction memory) Separate cache channels and caches, probably backed by same main memory actually used in some CPU In CdM-8, first approach (bit extension) is used One ISA-level change: ldc (LoaD Constant) instruction to read data from instruction memory

Coccone: most advanced version of CdM-8 Extension of CdM-8 architecture and schematics intended to demonstrate basic concepts of protected-memory operating systems In second semester we offer team project: actually building OS for this machine But what we need to build an operating system?

Processes (tasks) Most (but not all) modern operating systems have concept of process Process is a virtual machine (or a sandbox) with limited access, that runs in isolated memory space Process virtual machine is NOT emulating full access to system hardware (unlike hypervisor virtual machines like VMWare or VirtualBox) All programs you write in C programming course and most other programs you use (including CocoIDE) are designed to be run as processes and use operating system services to access hardware

What we need to protect memory Essentially, we need to catch every memory access for a running program Catch all memory accesses programmatically In fact, we need to interpret entire machine code of your program This is called byte-level interpretation This is how cocoemu actually works Orders of magnitude slower than hardware interpretation Can be significantly sped up by JiT compilation JiT is what Java, C# and many hypervisor virtual machines actually do, but this is far beyond scope of our course

Catch all memory accesses in hardware Insert a hardware device (MMU for Memory Management Unit) between CPU and memory bank Coccone is using one of simplest known types of MMU, known as memory banks Coccone uses 3 previously unused bits in PS register as bank selector In tome.pdf and in Logisim schemes it is also referenced as page Bits 0-3 - CVZN flags, bit 7 - interrupt enable, bits 4-6 - selector So, we can use 8 memory banks 256 bytes each Actually, there are 10 banks, but more on this later

Coccone memory subsystem page! data/code ! mem! in! addr! IO-15! MMU? VBR! I/Osel! bank select! 9! bank? 0? (code)? bank? 1? (code)? bank? 2? (code)? bank? 3? (code)? I/O bus! OS? ? RAM? (data)? bank? 4? RAM? bank? 5? RAM? bank? 6? RAM? bank? 7? RAM? Figure 14.2: Coccone memory subsystem Bit(s) 7 6 4 3 0 Description interrupt enable page no CVZN flags The new field in the PS is page number . The processor sees memory as one consisting of up to 8 size-256 pages , which could be separate memory units (banks) or segments of a singlememory device addressed by 8+3=11 bits, or indeed anything in between. That is why we use the term page when we talk about the processor s abstract view of the memory subsystem and the term bank to refer to a physical memory device. The difference between pages and banks would not merit an extra term if it were not for the fact that separate memory units are not just equivalent to a single unit in capacity and addressability, they surpass it in concurrency. While the single memory unit is perfectly capable of keeping all pages in it, it cannot be part ROM and part RAM, and different segmentsof it cannot beaddressed simultaneously in thesameclock cycle (as is the case in Coccone when its DMA is active). Another source of complications is the difference between Harvard and von Neumann architectures. Coccone utilises ... both, and for a good reason, which makes the relationship between pages and banks even less straightforward. M emory architecture. in figure14.2. Asonecan see, it isa rather complex arrangement which pursuesthegoal of clean separation between the OS and the user space to achieve both safety and enhanced Platform 2 functionality. The subsystem includes as many as 9 banks of memory, four of which are ROM banks containing parts of an operating system. Thearhictectureismixed: Harvard for theOSand von Neumann for user programs. The code for the OS resides in banks 0 3 and the OS data is kept in a single dedicated RAM bank marked as OSdata (and isleft unnumbered for that matter). Thecodein any OScode bank can also usebanks 4 7 as data memory. This is necessary for the OS to be able to read and write user data during system calls. The data address space for theOS includes the I/ O segment 0xf0 0xff, which is, as before, used for interaction with I/ O devices over the I/ O bus in memory-mapped mode. The memory subsystem of the Coccone machine is displayed diagrammatically Memory for user programs(banks4 7) iscompletely different. First of all, it isRAM and it is, asmentioned before, von Neumann. That is, all user code and data goes into the same memory bank. Secondly, all 256 291

Memory banks are not equal Banks 0-3 are reserved for OS code (even simplest OS won t fit in single bank) When bank 0-3 is active, CPU switches to Harvard mode and can use special 9thbank of RAM for data When bank 4-7 is active, CPU switches to Manchester mode and uses the same bank for code and data Banks 4-7 are for [user] processes Bank 10 is for memory-mapped I/O This is controlled by VBR MMU register (byte 0xff of OS data/IO pages)

VBR (Virtual Bank Register) Not available in user mode (code banks 4-7) Can select one of user mode banks, OS data bank I/O page for data access in system mode (code banks 0-3)

How to copy data from OS to user bank? 297 298 299 300 301 302 303 304 305 306 307 ldi r2,data.KBusr ld r2,r2 # memory bank # r2=memory bank ldi r0,MMU st r0,r2 #r0-> MMU I/O reg # set data memory bank st r1,r3 inc r1 # set data memory bank # advance buffer pointer clr r2 st r0,r2 # MMU reset to page 0 #

But how to actually switch banks? When we write to bank selector, this is indirect jump (PC now points to different bank but to same position in the bank) One solution: place a same piece of code in every bank This code will handle bank switching This approach is used in many 8-bit CPU with memory banks Actually, this is used in many OS for 32- and 64-bit CPUs. A All OS for x86 are using this approach (OS kernel is mapped to same addresses in all processes)

And how actually change bits 4-6 of PS? We know only two instructions that load and store full PS register: ioi and rti We can use rti to put arbitrary value in PS (push it and then rti) But rti is also a control transfer (considering a previous slide, this is good!) And you can use ioi to call procedures in other banks (just place right PS value at vector 0!) (Actually, many OSes use software interrupts for system calls) Also, special instruction osix with single operand (equivalent to ioi to vector 0, but bits 0-6 of new PS are taken from the operand)

But how interrupts work in multibank system? Where interrupt vectors are placed? What happens to the stack? Coccone always takes interrupt vectors from bank 0 But the vector contains a bank selector, so the handler can be placed in different bank! Coccone stack pointer is shadowed There are actually 8 stack pointers, one for every bank ==one per process But during interrupts, SP[0] is always used, so placing ISR in other banks require extra work

More on osix and rti osix can select target bank and set flags in PS Handler in the bank can use flags and conditional branches to decode syscall number We can have 4x16=64 useful syscalls (pointing to OS code pages) And also 64 useless syscalls pointing to user code pages Useless syscalls actually disturb system operation, so coccone is not as protected as real protected memory systems rti can put arbitrary values to PS on return Syscalls can use flags to indicate failure or success Syscalls can pass parameters in registers We ve seen how syscalls can copy data to user space, so we can pass pointers as parameters