Todays Topics Project 1 questions Less than a week left, should be - - PowerPoint PPT Presentation

today s topics
SMART_READER_LITE
LIVE PREVIEW

Todays Topics Project 1 questions Less than a week left, should be - - PowerPoint PPT Presentation

Todays Topics Project 1 questions Less than a week left, should be in Phase III But its really about logging the hours Test, test, test Runtime systems introduction Goal Bridging concepts Domain analysis


slide-1
SLIDE 1

Today’s Topics

  • Project 1 questions

Less than a week left, should be in Phase III But it’s really about logging the hours Test, test, test

  • Runtime systems introduction

Goal Bridging concepts Domain analysis

slide-2
SLIDE 2

Today’s Topics

  • Project 1 questions

Less than a week left, should be in Phase III But it’s really about logging the hours Test, test, test

  • Runtime systems introduction

Goal Bridging concepts Domain analysis

Live Presentation

  • http://www.cse.ucsd.edu/classes/wi05/cse131b/
  • “Live Presentations”
  • “IA-and-runtime-intro”
  • Password “cse131b”

Live Presentation

  • http://www.cse.ucsd.edu/classes/wi05/cse131b/
  • “Live Presentations”
  • “IA-and-runtime-intro”
  • Password “cse131b”
slide-3
SLIDE 3

Runtime Systems – A Look Ahead

VAR x, y: INTEGER; BEGIN x := x + y; END.

slide-4
SLIDE 4

Runtime Systems – A Look Ahead

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

slide-5
SLIDE 5

Runtime Systems – A Look Ahead

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call
slide-6
SLIDE 6

Runtime Systems – A Look Ahead

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

slide-7
SLIDE 7

Runtime Systems – Base + Offset

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

slide-8
SLIDE 8

Runtime Systems – Oberon Int Sparc Int

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

slide-9
SLIDE 9

Runtime Systems – Calling with Stack

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

slide-10
SLIDE 10

Runtime Systems – Bridging Concepts

VAR x, y: INTEGER; BEGIN x := x + y; END.

.seg "data" globals: .common _x,0x4,"data" .common _y,0x4,"data" .seg "text" _main: set globals, %g7 !#PROLOGUE# 0 ; allocate stack frame (locals) sethi %hi(LF14),%g1 add %g1,%lo(LF14),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 ld [%g7+4],%o0 ; y ld [%g7+0],%o1 ; x add %o1,%o0,%o1 ; add st %o1,[%g7+0] ; x <- ret ; return from function restore ; free stack frame space (locals) LF14 = -64 ; total size of main's stack frame

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Huge step to take

  • Oberon names to addrs
  • Load variables into regs
  • Call a function
  • Return to place of call

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

Different paradigms

  • Names vs. addrs/regs
  • calls vs. gotos
  • typed vs. untyped
  • infinite user types vs. few

simple types

Bridging principles

  • map in general to arithmetic
  • scope base pointer
  • decl order storage order
  • stack for nested calls/memory

Bridging principles

  • map in general to arithmetic
  • scope base pointer
  • decl order storage order
  • stack for nested calls/memory
slide-11
SLIDE 11

Structure of Oberon (Domain Analysis)

Question Answers (Java, Oberon) .

Procedure calls recursive? Procedure decls nest? Parameter-passing modes? Procedure parameters? Procedures returned as results? Dynamically created storage? Dynamic storage deallocated by programmer?