Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

A. Frederick Rosene

dblp:75/10973 · DBLP profile ↗
← Back
3ranked-venue papers
2as first author
0since 2021 · last 1978
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 3 · 2 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
3 papers
Memory systems · 65% Processor architecture and microarchitecture · 22% Parallel and multicore computing · 13%

Topics — the 6 heaviest of 7, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Processor architecture and microarchitecture › instruction set architecture › ISA specification
addressing modes
0.011967
Memory Allocation for Multiprocessors · IEEE Trans. Electron. Comput. 1967
Memory systems › memory access
indirect addressing
0.011967
Memory Allocation for Multiprocessors · IEEE Trans. Electron. Comput. 1967
Memory systems › memory management
memory allocation
0.011967
Memory Allocation for Multiprocessors · IEEE Trans. Electron. Comput. 1967
Memory systems
memory protection
0.011967
Memory Protection in Multiprocessing Systems · IEEE Trans. Electron. Comput. 1967
Parallel and multicore computing
multiprocessor system
0.011967
Memory Allocation for Multiprocessors · IEEE Trans. Electron. Comput. 1967
Parallel and multicore computing › multiprocessor system
shared-memory multiprocessor
0.011967
Memory Protection in Multiprocessing Systems · IEEE Trans. Electron. Comput. 1967

Methods — techniques the papers use, named apart from their topics

hardware protection mechanisms · 0.0
YearPublicationVenuePosition
1978 Phoenix system overview
A. Frederick Rosene
DAC1
1967 Memory Protection in Multiprocessing Systems
abstract
In a multiprocessor system where a bank of processors share a bank of memories, it becomes necessary to equip a processor with the capability to periodically deny to other processors access to certain memory locations. We call this the memory-protection problem because the processor which has gained access to the data must protect it from others. The type of data contained in the memory locations to be protected dictates the characteristics of the protection techniques which are applicable. This paper outlines the techniques as they apply to four classes of data which are defined for multiprocessor systems. In those cases where special hardware is required, such hardware is described. Furthermore, the programming implications and the error control problems are discussed.
John Roder, A. Frederick Rosene
IEEE Trans. Electron. Comput.2
1967 Memory Allocation for Multiprocessors
abstract
In multiprocessor systems it is desirable to look for and allocate storage without extensive data moving. Two techniques for accomplishing this, associative memory techniques and indirect addressing techniques, are described. It is concluded that the two methods are similar in performance, but that indirect addressing is more economical. An indirect addressing method is described in detail and various methods of implementation compared. The memory overhead and the time penalty (in memory accesses) are given as a function of memory size and method of implementation. It is concluded that a computed address table look-up technique should be used and that the block size should be either 256 or 512 words.
A. Frederick Rosene
IEEE Trans. Electron. Comput.1