DOCSLIB.ORG

64-Bit Technology

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

64-BIT TECHNOLOGY 64-bit From Wikipedia, the free encyclopedia. In computer architecture, 64-bit is an adjective N-bit Processors used to describe integers, memory addresses or 4- 8- 16- 24- 31- 32- 48- 64- 128- other data units that are at most 64 bits (8 bit bit bit bit bit bit bit bit bit octets) wide, or to describe CPU and ALU architectures based on registers, address buses, N-bit Applications or data buses of that size. 16- 31- 32- 64- bit bit bit bit As of 2004, 64-bit CPUs are common in N-bit Data Sizes servers, and have recently been introduced to 4- 8- 16- 32- 64- 128- the (previously 32-bit) mainstream personal computer arena in the form of the AMD64, bit bit bit bit bit bit EM64T, and PowerPC 970 (or "G5") processor nibble byte octet word dword qword architectures. These definitions are relevant to the world of x86 processors. See linked articles for Although a CPU may be 64-bit internally, its discussion of the meaning in other external data bus or address bus may have a architectures. The 31-bit and 48-bit sizes different size, either larger or smaller, and the relate to IBM mainframes and AS/400s, respectively. term is often used to describe the size of these buses as well. For instance, many current machines with 32-bit processors use 64-bit buses, and may occasionally be referred to as "64-bit" for this reason. The term may also refer to the size of an instruction in the computer's instruction set or to any other item of data. Without further qualification, however, a computer architecture described as "64-bit" generally has integer registers that are 64 bits wide and thus directly supports dealing both internally and externally with 64- bit "chunks" of data. Architectural implications Registers in a processor are generally divided into three groups: integer, floating point, and other. In all common general purpose processors, only the integer registers are capable of storing pointer values (that is, an address of some data in memory). The non- integer registers cannot be used to store pointers for the purpose of reading or writing to memory, and therefore cannot be used to bypass any memory restrictions imposed by the size of the integer registers. Nearly all common general purpose processors (with the notable exception of the ARM and most 32-bit MIPS implementations) have integrated floating point hardware, which may or may not use 64 bit registers to hold data for processing. For example, the AMD64 architecture defines a SSE unit which includes 16 128-bit wide registers, and the traditional x87 floating point unit defines 8 80-bit registers in a stack configuration. By contrast, the 64-bit Alpha family of processors defines 32 64-bit wide floating point registers in addition to its 32 64-bit wide integer registers. Memory limitations Most CPUs are currently (c. 2005) designed so that the contents of a single integer register can store the address (location) of any datum in the computer's virtual memory. Therefore, the total number of addresses in the virtual memory — the total amount of data the computer can keep in its working area — is determined by the width of these registers. Beginning in the 1960s with the IBM System 360, then (amongst many others) the DEC VAX minicomputer in the 1970s, and then with the Intel 80386 in the mid- 1980s, a de facto consensus developed that 32 bits was a convenient register size. A 32- bit register meant that 232 addresses, or 4 gigabytes of RAM memory, could be referenced. At the time these architectures were devised, 4 gigabytes of memory was so far beyond the typical quantities available in installations that this was considered to be enough "headroom" for addressing. 4-gigabyte addresses were considered an appropriate size to work with for another important reason: 4 billion integers are enough to assign unique references to most physically countable things in applications like databases. However, with the march of time and the continual reductions in the cost of memory (see Moore's Law), by the early 1990s installations with quantities of RAM approaching 4 gigabytes began to appear, and the use of virtual memory spaces exceeding the 4- gigabyte ceiling became desirable for handling certain types of problems. In response, a number of companies began releasing new families of chips with 64-bit architectures, initially for supercomputers and high-end workstation and server machines. 64-bit computing has gradually drifted down to the personal computer desktop, with Apple Computer's PowerMac desktop line as of 2003 and its iMac home computer line (as of 2004) both using 64-bit processors (the G5 chip from IBM), and AMD's "AMD64" architecture (cloned by Intel as "EM64T") becoming common in high-end PCs. Timeline • 1991: MIPS Technologies produced the first 64-bit CPU, as the third revision of their MIPS RISC architecture, the R4000. The CPU was commercially available in 1991 and used in SGI graphics workstations starting with the Indigo series, running the 64-bit version of the IRIX operating system. • 1994: Intel announced plans for the 64-bit IA-64 architecture (jointly developed with HP) as a successor to its 32-bit IA-32 processors. A 1998-1999 launch date was targeted. • 1995: Fujitsu-owned HAL Computer Systems launched workstations based on a 64-bit CPU, HAL's independently designed first generation SPARC64. IBM released 64-bit AS/400 systems, with the upgrade able to convert the operating system, database and applications. • 1996: Sun and HP released their 64-bit processors, the UltraSPARC and the PA-8000. Sun Solaris, IRIX, and other variants of UNIX continued to be common 64-bit operating systems. • 1999: Intel released the instruction set for the IA-64 architecture. First public disclosure of AMD's set of 64-bit extensions to IA-32 called x86-64. • 2000: IBM shipped its first 64-bit mainframe, the zSeries z900, and its new z/OS operating system — culminating history's biggest 64-bit processor development investment and instantly wiping out 31-bit plug-compatible competitors Fujitsu/Amdahl and Hitachi. 64-bit Linux on zSeries followed almost immediately. • 2001: Intel finally shipped its 64-bit processor line, now branded Itanium, targeting high-end servers. It fails to meet expectations due to the repeated delays getting IA-64 to market, and becomes a flop. Linux was the first operating system to run on the processor at its release. • 2002: Intel introduced the Itanium 2 as a successor to the Itanium. • 2003: AMD brought out its 64-bit Opteron and Athlon 64 processor lines. Apple also shipped 64-bit PowerPC chips courtesy of IBM and Motorola, along with an update to its Mac OS X operating system. Several Linux distributions released with support for x86-64. Microsoft announced that it would create a version of its Windows operating system for the AMD chips. Intel maintained that its Itanium chips would remain its only 64-bit processors. • 2004: Intel, reacting to the market success of AMD, admitted it had been developing a clone of the x86-64 extensions, which it calls EM64T. Updated versions of its Xeon and Pentium 4 processor families supporting the new instructions were shipped. • 2005: In March, Intel announced that their first dual-core processors will ship in the second quarter 2005 with the release of the Pentium Extreme Edition 840 and the new Pentium D chips. Dual-core Itanium 2 processors will follow in the fourth quarter. • 2005: On April 18, Beijing Longxin rolled out its first x86-64 compatible CPU, named Longxin II. The thumb sized square chip gathers 13.5 million transistors with a peak capacity of 2 billion calculations per second for a single accuracy check and 1 billion calculations per second under a dual accuracy check. The new chip registers a maximum frequency of 500MHz and a power consumption ranging from 3 to 5 watts. • 2005: On April 30, Microsoft publicly released Windows XP x64 Edition for x86-64 processors. • 2005: In May, AMD pre-released its dual-core desktop processor family called Athlon 64 X2. Athlon 64 X2 (Toledo) processors feature two cores with 1MB of L2 cache memory per core and consist of about 233.2 million transistors. They are 199 mm² large. • 2005: In July, IBM announced its new dual-core 64-bit PowerPC 970MP (codenamed Antares). 32 vs 64 bit A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as most operating systems must be extensively modified to take advantage of the new architecture. Other software must also be ported to use the new capabilities; older software is usually supported through either a hardware compatibility mode (in which the new processors support an older 32-bit instruction set as well as the new modes), through software emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor die (as with the Itanium2 processors from Intel). One significant exception to this is the AS/400, whose software runs on a virtual ISA which is implemented in low-level software. This software, called TIMI, is all that has to be rewritten to move the entire OS and all software to a new platform, such as when IBM transitioned their line from 32-bit POWER to 64-bit POWER. While 64-bit architectures indisputably make working with huge data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks.
Recommended publications
  • Intermediate X86 Part 2

    Intermediate X86 Part 2

    Intermediate x86 Part 2 Xeno Kovah – 2010 xkovah at gmail All materials are licensed under a Creative Commons “Share Alike” license. • http://creativecommons.org/licenses/by-sa/3.0/ 2 Paging • Previously we discussed how segmentation translates a logical address (segment selector + offset) into a 32 bit linear address. • When paging is disabled, linear addresses map 1:1 to physical addresses. • When paging is enabled, a linear address must be translated to determine the physical address it corresponds to. • It’s called “paging” because physical memory is divided into fixed size chunks called pages. • The analogy is to books in a library. When you need to find some information first you go to the library where you look up the relevant book, then you select the book and look up a specific page, from there you maybe look for a specific specific sentence …or “word”? ;) • The internets ruined the analogy! 3 Notes and Terminology • All of the figures or references to the manual in this section refer to the Nov 2008 manual (available in the class materials). This is because I think the manuals <= 2008 organized and presented much clearer than >= 2009 manuals. • When I refer to a “frame” it means “a page- sized chunk of physical memory” • When paging is enabled, a “linear address” is the same thing as a “virtual memory ” “ ” address or virtual address 4 The terrifying truth revealed! And now you knowAHHHHHHHH!!!…the rest of the story.(Nah, Good it’s not so bad day. :)) 5 Virtual Memory • When paging is enabled, the 32 bit linear address space can be mapped to a physical address space less than 32 bits.
  • Descriptive Analysis of Human Remains from the Fuller and Fanning Mounds

    Descriptive Analysis of Human Remains from the Fuller and Fanning Mounds

    AN ABSTRACT OF THE THESIS OF David Stepp for the degree of Master of Arts in Interdisciplinary Studies in the co- departments of Anthropology, Zoology, and Statistics presented onFebruary 2, 1994. Title :Descriptive Analysis of Human Remains from the Fuller and Fanning Mounds, Yamhill River, Willamette Valley, Oregon Redacted for Privacy Abstract Approved : Roberta Hall The study presents the results of a descriptive analysis of the skeletal remains of 66 individuals recovered from the Fuller and Fanning Mound sites, located on the Yamhill River, Willamette Valley, Oregon, excavated in 1941-42 by W. T. Edmundson and William S. Laughlin. The literature and original field notes have been analyzed, and a description of burial type, side, orientation, grave type, associations, original preservation, and other information has been compiled for each individual. A tally of each of these burial attributes for the Yamhill population as a whole is also completed. In addition, an assessment of age, sex, and stature, a series of craniometric measurements, and non-metric traits, a dental analysis, and general description of obvious pathologic and morphologic condition of each individual and the group as a whole have been accomplished. Differences in trade item associations between deformed and non-deformed individuals suggest either a later arrival of cranial deformation practices (and possibly another cultural group) to the area, and possibly a multiple occupation of the Fuller and Fanning sites, or an elite class separation defined in part by artificial deformation of crania. Cranial deformation is also associated with the frequency of certain cranial discrete traits. Sexual dimorphism was noted in metric but not in non-metric analyses.
  • Multiprocessing Contents

    Multiprocessing Contents

    Multiprocessing Contents 1 Multiprocessing 1 1.1 Pre-history .............................................. 1 1.2 Key topics ............................................... 1 1.2.1 Processor symmetry ...................................... 1 1.2.2 Instruction and data streams ................................. 1 1.2.3 Processor coupling ...................................... 2 1.2.4 Multiprocessor Communication Architecture ......................... 2 1.3 Flynn’s taxonomy ........................................... 2 1.3.1 SISD multiprocessing ..................................... 2 1.3.2 SIMD multiprocessing .................................... 2 1.3.3 MISD multiprocessing .................................... 3 1.3.4 MIMD multiprocessing .................................... 3 1.4 See also ................................................ 3 1.5 References ............................................... 3 2 Computer multitasking 5 2.1 Multiprogramming .......................................... 5 2.2 Cooperative multitasking ....................................... 6 2.3 Preemptive multitasking ....................................... 6 2.4 Real time ............................................... 7 2.5 Multithreading ............................................ 7 2.6 Memory protection .......................................... 7 2.7 Memory swapping .......................................... 7 2.8 Programming ............................................. 7 2.9 See also ................................................ 8 2.10 References .............................................
  • X86 Memory Protection and Translation

    X86 Memory Protection and Translation

    2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory x86 Memory Protection and Threads Formats Allocators Translation User System Calls Kernel Don Porter RCU File System Networking Sync Memory Device CPU Today’s Management Drivers Scheduler Lecture Hardware Interrupts Disk Net Consistency 1 Today’s Lecture: Focus on Hardware ABI 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Lecture Goal Undergrad Review • Understand the hardware tools available on a • What is: modern x86 processor for manipulating and – Virtual memory? protecting memory – Segmentation? • Lab 2: You will program this hardware – Paging? • Apologies: Material can be a bit dry, but important – Plus, slides will be good reference • But, cool tech tricks: – How does thread-local storage (TLS) work? – An actual (and tough) Microsoft interview question 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Memory Mapping Two System Goals 1) Provide an abstraction of contiguous, isolated virtual Process 1 Process 2 memory to a program Virtual Memory Virtual Memory 2) Prevent illegal operations // Program expects (*x) – Prevent access to other application or OS memory 0x1000 Only one physical 0x1000 address 0x1000!! // to always be at – Detect failures early (e.g., segfault on address 0) // address 0x1000 – More recently, prevent exploits that try to execute int *x = 0x1000; program data 0x1000 Physical Memory 5 6 5 6 1 2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Outline x86 Processor Modes • x86
  • ORE-18 Van Duzer-Steel Bridge Road Corridor Refinement

    ORE-18 Van Duzer-Steel Bridge Road Corridor Refinement

    H.B. VAN DUZER FOREST CORRIDOR TO STEEL BRIDGE ROAD Oregon Highway Routes Salmon River Highway ORE-18 Three Rivers Highway ORE-22 CORRIDOR REFINEMENT PLAN June 2001; Amended and Edited May 2004 Preface The H.B. Van Duzer Forest Corridor to November 2002. The Revised Location Steel Bridge Road Draft Corridor Environmental Assessment, completed in Refinement Plan was first produced as a 2004, includes the interchange as a paper document during July 2000. component of the Preferred Alternative. Amendments to the Draft Refinement Plan were published as a series of replacement In this report, you will find text and figures pages in February 2001. This document that describe the existing conditions, traffic includes those amendments. It also includes forecasts, preferred solutions, and several changes from a new Preferred Alternative alternatives that were considered. Figures that includes a different interchange and referenced in the document are hyperlinked interchange location for the ORE-18/Fort in the document text, but are provided Hill Road/South Yamhill River Road separately due to the cumulative size of all connection. In addition, this version the electronic files. The report can be includes Polk County’s 2001 printed in its entirety, or as separate sections Comprehensive Plan Map and Land Use or pages. Please note, however, that the Zoning Map (Figures 3-10, entire document on this CD is over 200 3-11, 3-12). These map amendments show pages in length. It contains 28 figures based the changes adopted by Polk County to upon aerial photography in jpeg format. reflect the recommendations of the Regional Paper copies of this document have not been Problem Solving Committee.
  • Operating Systems & Virtualisation Security Knowledge Area

    Operating Systems & Virtualisation Security Knowledge Area

    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
  • Chapter 3 Protected-Mode Memory Management

    Chapter 3 Protected-Mode Memory Management

    CHAPTER 3 PROTECTED-MODE MEMORY MANAGEMENT This chapter describes the Intel 64 and IA-32 architecture’s protected-mode memory management facilities, including the physical memory requirements, segmentation mechanism, and paging mechanism. See also: Chapter 5, “Protection” (for a description of the processor’s protection mechanism) and Chapter 20, “8086 Emulation” (for a description of memory addressing protection in real-address and virtual-8086 modes). 3.1 MEMORY MANAGEMENT OVERVIEW The memory management facilities of the IA-32 architecture are divided into two parts: segmentation and paging. Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple programs (or tasks) can run on the same processor without interfering with one another. Paging provides a mech- anism for implementing a conventional demand-paged, virtual-memory system where sections of a program’s execution environment are mapped into physical memory as needed. Paging can also be used to provide isolation between multiple tasks. When operating in protected mode, some form of segmentation must be used. There is no mode bit to disable segmentation. The use of paging, however, is optional. These two mechanisms (segmentation and paging) can be configured to support simple single-program (or single- task) systems, multitasking systems, or multiple-processor systems that used shared memory. As shown in Figure 3-1, segmentation provides a mechanism for dividing the processor’s addressable memory space (called the linear address space) into smaller protected address spaces called segments. Segments can be used to hold the code, data, and stack for a program or to hold system data structures (such as a TSS or LDT).
  • X86 Memory Protection and Translation

    X86 Memory Protection and Translation

    x86 Memory Protection and Translation Don Porter CSE 506 Lecture Goal ò Understand the hardware tools available on a modern x86 processor for manipulating and protecting memory ò Lab 2: You will program this hardware ò Apologies: Material can be a bit dry, but important ò Plus, slides will be good reference ò But, cool tech tricks: ò How does thread-local storage (TLS) work? ò An actual (and tough) Microsoft interview question Undergrad Review ò What is: ò Virtual memory? ò Segmentation? ò Paging? Two System Goals 1) Provide an abstraction of contiguous, isolated virtual memory to a program 2) Prevent illegal operations ò Prevent access to other application or OS memory ò Detect failures early (e.g., segfault on address 0) ò More recently, prevent exploits that try to execute program data Outline ò x86 processor modes ò x86 segmentation ò x86 page tables ò Software vs. Hardware mechanisms ò Advanced Features ò Interesting applications/problems x86 Processor Modes ò Real mode – walks and talks like a really old x86 chip ò State at boot ò 20-bit address space, direct physical memory access ò Segmentation available (no paging) ò Protected mode – Standard 32-bit x86 mode ò Segmentation and paging ò Privilege levels (separate user and kernel) x86 Processor Modes ò Long mode – 64-bit mode (aka amd64, x86_64, etc.) ò Very similar to 32-bit mode (protected mode), but bigger ò Restrict segmentation use ò Garbage collect deprecated instructions ò Chips can still run in protected mode with old instructions Translation Overview 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only ò Segmentation cannot be disabled! ò But can be a no-op (aka flat mode) x86 Segmentation ò A segment has: ò Base address (linear address) ò Length ò Type (code, data, etc).
  • Computer Architectures an Overview

    Computer Architectures an Overview

    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
  • Four Deaths: the Near Destruction of Western

    Four Deaths: the Near Destruction of Western

    DAVID G. LEWIS Four Deaths The Near Destruction of Western Oregon Tribes and Native Lifeways, Removal to the Reservation, and Erasure from History THE NOTIONS OF DEATH and genocide within the tribes of western Oregon are convoluted. History partially records our removal and near genocide by colonists, but there is little record of the depth of these events — of the dramatic scale of near destruction of our peoples and their cultural life ways. Since contact with newcomers, death has come to the tribes of western Oregon in a variety of ways — through epidemic sicknesses, followed by attempted genocide, forced marches onto reservations, reduction of land holdings, broken treaty promises, attempts to destroy tribal culture through assimilation, and the termination of federal recognition of sovereign, tribal status. Death, then, has been experienced literally, culturally, legally, and even in scholarship; for well over a century, tribal people were not consulted and were not adequately represented in historical writing. Still, the people have survived, restoring their recognized tribal status and building structures to maintain and regain the people’s health and cultural well-being. This legacy of death and survival is shared by all the tribes of Oregon, though specific details vary, but the story is not well known or understood by the state’s general public. Such historical ignorance is another kind of death — one marked by both myth and silence. An especially persistent myth is the notion that there lived and died a “last” member of a particular tribe or people. The idea began in the late nineteenth century, when social scientists who saw population declines at the reservations feared that the tribes would die off before scholars could collect their data and complete their studies.
  • Whiteson Park Conceptual Master Plan Whiteson Area Park Conceptual Master Plan June 1, 2016

    Whiteson Park Conceptual Master Plan Whiteson Area Park Conceptual Master Plan June 1, 2016

    WHITESON PARK CONCEPTUAL MASTER PLAN WHITESON AREA PARK CONCEPTUAL MASTER PLAN JUNE 1, 2016 ACKNOWLEDGMENTS CSC PROJECT TEAM This document was developed for Yamhill Project Associates County Parks by the University of Oregon’s Greg Oldson, MLA Community Service Center (CSC). The Keegan Oneal, MLA Candidate CSC project team would like to thank the Rory Isbell, JD / MCRP Candidate County Parks and Recreation Advisory Board, Parks Director Brett Henry, and Project Manager Whiteson Advisory Team members for Bethany Steiner their assistance with this project. A special thanks goes to the residents who took Community Service Center the time to participate in interviews and 1209 University of Oregon meetings with the project team. Eugene, OR 97403 Phone: 541-346-3615 http://csc.uoregon.edu 2 TABLE OF CONTENTS INTRODUCTION 4 Purpose Background Vision Project Timeline EXISTING CONDITIONS AND SITE ANALYSIS 6 DESIGN AND PLANNING PROCESS 12 Project Goals CONCEPTUAL MASTER PLAN 13 Park Activities IMPLEMENTATION COSTS AND PRIORITIES 16 Park Development Phases Cost Estimates APPENDIX 31 A - Site Opportunities and Constraints B - Stakeholder Involvement: Schematic Design & Meetings C - Partnership Opportunities D - Funding Resources E - Meeting Attendees F - Site Photo Inventory 3 INTRODUCTION PURPOSE the County Park and Recreation department goal of these meetings and interviews was to The purpose of the Whiteson Park Master decided that more analysis and community collect honest and updated input regarding Plan is to provide Yamhill County Parks input needed to happen before the County issues and opportunities presented by the and Recreation with an updated vision and moved forward with developing the park. site. These issues and opportunities were conceptual design for the development of In 2015, the County partnered with the then synthesized into a more holistic design the Whiteson Park property.
  • Watershed Characteristics

    Watershed Characteristics

    SECTION 2 Watershed Characteristics This section describes drainage characteristics unique to the City of McMinnville and the watersheds that drain through the City. The following drainage characteristics are summarized: location, study area parameters, climate, soil conditions, topography, groundwater, existing drainage facilities, and existing and future land use conditions. This information will be used in the master plan to evaluate the performance of the existing drainage facilities and to identify future drainage requirements. 2.1 Location The City of McMinnville is located in Yamhill County, situated in the northern Willamette Valley between the Coastal and Cascade Mountain ranges. It is approximately 35 miles southwest of Portland and 26 miles northwest of Salem, Oregon. The City of McMinnville is mostly situated between the North and South Forks of the Yamhill River just upstream of their confluence. The Yamhill River flows northeastward from McMinnville approximately 7 miles before reaching the Willamette River. Four major waterways drain the City of McMinnville: Cozine Creek with its branches, Baker Creek, North Yamhill River, and the South Yamhill River. Figure 2-1, Topography Map, shows the location of these four major waterways. The area of the entire watershed that drains McMinnville and drains through the McMinnville urban growth boundary (UGB) is approximately 10,727 acres, 50 percent of which is drained by Cozine Creek. Cozine Creek, in turn, discharges into the South Fork of the Yamhill River. 2.2 Study Area Delineation While this master plan considers the runoff impact from the entire watershed that drains through the City, the specific study area for this plan is the McMinnville UGB.