Computer architecture and assembly language

course at CMC MSU:

way to survive

George V. Kouryachy

Mikhail E. Rudachenko

Why?

  • It's a basic course (2nd semester)
  • It's only a semester long
  • It requires both theory and labs
  • Now CMC students can (not) choose from
    • Simple, but outdated course
    • Modern, but overstructured course

Basic Course

  • Aim:
    • the reason behind computer architecture
    • …supported by practice
  • Goals:
    • Simulation of diverse model CPU types
    • Modern computer architecture principles
    • …illustrated by autocode examples
    • Assembly language practice
  • Length: 54 a. h. lectures + 54 a. h. labs

Others

Officially there is also two educational paths

  • «Simple»
    • 16-bit Intel
    • MASM / DOS
  • «Modern»
    • x86_64
    • Nasm / Linux

Both concentrated on assembly more than on architecture

(for different reasons though)

How?

Model Machines

  • 3-address
  • 2-address
  • 1-address
  • Indeterminate length
  • Register

MIPS32

  • Still alive
  • Relatively simple instruction set with no legacy
  • ⇒ «Modern»/«Coherent» balance
  • Intelligible features (like pipe, cache etc.)
  • Easy to emulate (MARS, SPIM, QEMU, others)

It is contest management system, but also used for homework testing/checking

  • Used at MSU CMC
  • Rebuilds program before checking
  • Can verify (among others):
    • Program output over reference input/output
    • Program footprint and execution time
    • Program source
  • Both modelmachine.py and MARS run as GUI-less interpreters

What?

  • Model Machines
  • MARS:
    • Simulator+IDE
    • Peripherials
    • Cache
    • Graphics

Model Machines

  • Hexadecimal code
  • Text program format
  • Input/output
  • Interpreter
  • Debugger
  • Primitive assembly
  • Writen in python
$ cat max3.mm                        
mm2

[config]
input= 0x100, 0x0101, 0x0102
output = 0x103

[code]
        00 0103 0100
        05 0103 0101
        86 0000 0004
        00 0103 0101
        05 0103 0102
        86 0000 0007
        00 0103 0102
        99 0000 0000

[input]

$ python3 -m modelmachine run max3.mm
5 7 1
7

MARS peripherials

  • MMIO
  • Polling
  • Interrupts
  • Kernel programming
  • … some virtual devices

Led + buttons

Console

MARS tools

 

  • Cache simulator
  • Branch history
  • FPU caclulator
  • Memory reference
  • CPU diagram
  • …others

MARS raster graphics

So?

Good practice coverage and technological scope

but

  • MM is good, but out of line
  • Feature lack in MARS: VM, DMA, multicore etc.
  • No time for another platform/emulator
  • Switch to RiscV maybe?

Results

  • Over 75% lectures are supported by labs
  • MM is too stiff framework by design
  • There's paradigm gap between MM and MIPS32
  • MARS does not cover all our needs
  • …but there's no time to involve more simulators
  • …say nothing of more architectures
  • Extra architecture models (e. g. stack machine)
  • MARS: Pipe is fuzzy (anoter sim is used)
  • Not in MARS:
    • Virtual memory
    • Vector / full superscalar flow
    • Multcore
    • Virtualization
    • Predictive calculations
  • Assembly to C bridge (absolutely no time)

Futher work

Any other questions?

George V. Kouryachy
(gmail/telegram/etc: FrBrGeorge)

Mikhail E. Rudachenko

Made with Slides.com