Browse Prior Art Database

Methods to isolate and control processor to memory transfers using indirect software procedures.

IP.com Disclosure Number: IPCOM000013798D
Original Publication Date: 2000-Jan-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 48K

Publishing Venue

IBM

Abstract

This invention provides the ability to create and control specific data transfers between the processor subsystem and the memory subsystem of a

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 3

  Methods to isolate and control processor to memory transfers using indirect software procedures.

    This invention provides the ability to create and control specific data transfers between the processor subsystem and the memory subsystem of a

computer. The intent is to create data traffic between the subsystems such that the transfer cycle type and the frequency of cycles (data throughput

or load) is strictly controlled. The ability to write/read cache lines between one or more processors' cache subsystem and the memory

subsystem was needed in an operating system like NT that prohibits direct control of caches because of the operating systems use of virtual memory

    and HAL(hardware abstraction layer). This method would allow us to efficienty measure performance and signal characteristics of the system as well

    as create a very powerful method to stress interactions between the processor/memory subsytems to insure that proper system integration has

been achieved(Specifically, this adds to the ability of an application memory exerciser to detect problems with the integration of those

subsystems in a running operating system.) Further, the type mechanisms should be effective via indirect control without regard to the specific

processor technology or operating system provided that certain processor and memory subsytem attributes like bus width, cache line size, and cache

capacities were known.

Currently, programs that fill memory use specific API call written by the operating vendor to provide a fast mechanism of loading memory. For instance, use Microsoft's NT 4.0 API calls like memset and memcpy. Most programmers use this approach because it's easy and they generally believe that memory fill type APIs were well optimized by the provider. An example of this approach is show below.

DWORD *m_dwByteAddress; int nData; DWORD m_dwNumberOfTransfers

cData = 0x02; Memset (m_dwByteAddress, nData, m_dwNumberOfTransfers);

These work quite well when you want to fill the contents of a memory buffer with a fixed type of data in applications where initialization occurs or when you need to copy from one buffer to another. In other words, if a programmer desires the function of filling or copying a memory but is unconcerned with how it works then he/she has a solution. However, in a memory test program you are concerned with how the memory transfer actually occurs as it relates to current hardware technology.

For instance, the code below does the same kind of operation as a NT memset API. It goes through the entire buffer in a sequential manner and fills it with the data that is desired. However, in todays Intel processor technology the processor cache line size is 32 bytes. That means that if the first memory dw write operation started perfectly aligned at the beginning of the cache line then all subsequent writes would be within the cache line until it's full. It would not even have the potential to be evicted from the cache to cause a processor to mem...