RUN-TIME STORAGE.ppt

RUN-TIME STORAGE Chuen-Liang Chen Department of Computer Science and Information Engineering National Taiwan University Taipei, TAIWAN Program layout (1/2) typical program layout each block can be allocated to a “segment” under segmented memory system operand stack is required for some computer; Its size can be determined at compile-time Program layout (2/2) for load-and-go compiler Static allocation space is allocated in fixed location for the life-time of a program applicable only when the number and size of data objects is known at compile-time suitable for global variables literals (or put them on a separate “literal pool” ) the only choice for early language (e.g. without recursion) preferable to address a data object as (DataArea, Offset) and binding DataArea at link-time Heap allocation space is allocated and freed at any time and in any order suitable for dynamic memory allocation/deallocation allocation -- in demand best-fit first-fit circular-first-fit QUIZ: comparison deallocation no deallocation (work for implementations with a large virtual memory) explicit deallocation implicit deallocation single reference reference count mark-and-sweep garbage collection [ + compaction] QUIZ: comparison free-space representation -- bit map, linked list Stack allocation (1/2) suitable for recursive call activation record (AR) -- data space required for a call push / pop, when “call” / “return” example -- procedure p(a:integer) is b: real; c: array (1..10) of real; d,e : array (1..N) of integer; begin b := c(a) * 2.51; end; 2.51 is stored in literal pool dope vector -- fixed size descriptor for dynamic array; containing size and bounds of array (determined at run-time) Stack allocation (2/2) when too many recursive callsT too many AR T too many registers solutions: display registers static and dynamic chains QUIZ: coroutine? QUIZ: variable declaration within block? Display registers (1/2) observation (by scoping rules) --at most one active scope for one