ROMmability
|
From: Andy Glew "newsgroup at on 1 Aug 2010 21:14 ROMmability refers to the ability to place the stuff needed by a computer system that must reside in memory - e.g. instructions, data, page tables - in ROM, read-only memory. = Hard ROMming vs. Soft ROMming = ROMmability might originally have referred to *hard* *ROMming* - truly having a read only memory. However, ROMmability is also of interest to soft ROMing: when memory is writeable, but where writing exacts a penalty. Such soft ROmming situations include * writeable but mainly read-only memory, where dirty pages would have to be paged out to disk, eventually if not immediately * COW page sharing - where writes may produce an expensive copy-on-write operation * FLASH memory and other write-limited memory in the memory hioerarchy. In such a soft ROMming situation, writes may be permitted, but gratuitous writes should be avoided. = Hardware vs. Software = Impediments to ROMmability are occasionally part of the hardware architecture, and are more often software artifacts. Here we list several ROMmability issues and/or their solutions, encounterd over the years. == Page Tables == Hardware. You might want to place the page tables in ROM. If the page tables have accessed and dirty bits (A & D bits) in the PTEs, and if these bits are set by hardware... and if an error, or performance loss, will occur if attempting to set such bits in a ROM... Workaround: set the A&D bits in the PTEs so no hardware setting of these bits occurs. If necessary, emulate the A&D bits by software traps. Some computer architects espouse placing the A&D bits in storage separate from the page tables. So,me espouse using a snoopy array. == Garbage Collection == Software You may want to place collections of objects in ROM - or in soft-ROM situations. Many garbage collectors require an object header, and set bits in that header as part of GC. Workaround: non-adjacent. == Dynamic Linking == Software There are two main ways of doing dynamic linking: 1. The slow way: all such library calls go through a table. The table lives in RAM, and can be patched. 2. The faster way: the binary is patched to call the shared library once loaded. The faster way has issues with ROMmability. Which may explain why the slower way is more popular, even though it often has considerably slower performance. Related: "method caching" in SOAR modified the call site in place. == Debugging == Hardware/Software Debugging by inserying breakpoint instructions obviously has ROMmability issues. Workaround (with limitations): hardware debug registers that, e.g., cause a debug trap if an instructikn address ([[PC or IP]]) or data address (or instruction opcode or data value, or sequence of said) is seen. = See = http://semipublic.comp-arch.net/wiki/ROMmability (cross posting to comp.arch)
From: Alex McDonald on 2 Aug 2010 12:19 On Aug 2, 2:14 am, Andy Glew <"newsgroup at comp-arch.net"> wrote: > ROMmability refers to the ability to place the stuff needed by a > computer system that must reside in memory - e.g. instructions, data, > page tables - in ROM, read-only memory. > > = Hard ROMming vs. Soft ROMming = > > ROMmability might originally have referred to *hard* *ROMming* - truly > having a read only memory. > > However, ROMmability is also of interest to soft ROMing: when memory is > writeable, but where writing exacts a penalty. Such soft ROmming > situations include > * writeable but mainly read-only memory, where dirty pages would have to > be paged out to disk, eventually if not immediately > * COW page sharing - where writes may produce an expensive copy-on-write > operation > * FLASH memory and other write-limited memory in the memory hioerarchy. > > In such a soft ROMming situation, writes may be permitted, but > gratuitous writes should be avoided. > > = Hardware vs. Software = > > Impediments to ROMmability are occasionally part of the hardware > architecture, > and are more often software artifacts. Here we list several ROMmability > issues and/or their solutions, encounterd over the years. > > == Page Tables == > > Hardware. > > You might want to place the page tables in ROM. > > If the page tables have accessed and dirty bits (A & D bits) in the > PTEs, and if these bits are set by hardware... and if an error, or > performance loss, will occur if attempting to set such bits in a ROM... > > Workaround: set the A&D bits in the PTEs so no hardware setting of these > bits occurs. > If necessary, emulate the A&D bits by software traps. > > Some computer architects espouse placing the A&D bits in storage > separate from the page tables. So,me espouse using a snoopy array. > > == Garbage Collection == > > Software > > You may want to place collections of objects in ROM - or in soft-ROM > situations. > > Many garbage collectors require an object header, and set bits in that > header as part of GC. > > Workaround: non-adjacent. > > == Dynamic Linking == > > Software > > There are two main ways of doing dynamic linking: > > 1. The slow way: all such library calls go through a table. The table > lives in RAM, and can be patched. > > 2. The faster way: the binary is patched to call the shared library once > loaded. > > The faster way has issues with ROMmability. Which may explain why the > slower way is more popular, > even though it often has considerably slower performance. > > Related: "method caching" in SOAR modified the call site in place. > > == Debugging == > > Hardware/Software > > Debugging by inserying breakpoint instructions obviously has ROMmability > issues. > > Workaround (with limitations): hardware debug registers that, e.g., > cause a debug trap if an instructikn address ([[PC or IP]]) or data > address (or instruction opcode or data value, or sequence of said) is seen. > > = See = > > http://semipublic.comp-arch.net/wiki/ROMmability(cross posting to > comp.arch) This is of interest and an area of very active research for my employer. The storage industry is adopting flash wholesale in two primary use cases; .. SSDs (solid state disks), where the onboard disk management firmware (FTL, or the Flash Translation Layer) makes local decisions about best use of a resource that is much more expensive to write as compared with read in terms of latency and has a limited number of such operations; .. cache, where decisions can be made at scale (at least, at a large group of blocks level rather than individual block on disk), and where wear leveling can be more globally addressed. The approach my company has taken to the semi-ROMable nature of flash is to use it for read-lookaside, and much like the example you give for garbage collection (non-adjacency) and dynamic linking (pointers, dirty bits in RAM), a combination of such approaches is used. It's an active area of research; as the characteristics and cost of flash changes, so do the approaches. A google search on "site:www.usenix.org flash cache" throws up a number of papers related to its use and the design of filesystems and mixed flash/disk based storage that might be of interest.
From: EricP on 2 Aug 2010 17:47 Andy Glew wrote: > ROMmability refers to the ability to place the stuff needed by a > computer system that must reside in memory - e.g. instructions, data, > page tables - in ROM, read-only memory. > This is dated, but... = Instruction Set = The Intel 8008 and 8080 had Input IN and Output OUT instructions that only allowed port addresses as an instruction immediate constant. To perform I/O to a arbitrary port address (one not known at compile/assembly time) you would generate the I/O instruction with a RET into writable memory and call it. To avoid interrupt reentrancy issues, this should done on the top of stack. Later the Z80 and 8086 added I/O instructions that allowed port addresses to be in a register. Data General Nova Input and Output instructions were similar, and IIRC also IBM 360 START CHANNEL, in only allowing immediate constant port address. While neither was interested in ROMability, performing arbitrary port I/O required generating and executing self modifying code which interacts with prefetch buffers. They later added register variants of I/O instructions. Eric
From: jacko on 2 Aug 2010 18:56 The purpose of ROMability is to fix a set of binary values immutable to the 'script engine' of a system, such that the device is not made into a useless thing. This would infer a FLASH ROM would need a physical switch throwing, and not some software only reprogramming routine. Real ROM has the advantage that moving bulk semiconductor via radiation is much more difficult than moving electron charge on a programable floating gate. Cheers jacko
From: Andy Glew "newsgroup at on 3 Aug 2010 03:26 On 8/2/2010 2:47 PM, EricP wrote: > Andy Glew wrote: >> ROMmability refers to the ability to place the stuff needed by a >> computer system that must reside in memory - e.g. instructions, data, >> page tables - in ROM, read-only memory. >> > > This is dated, but... > > = Instruction Set = > > The Intel 8008 and 8080 had Input IN and Output OUT instructions > that only allowed port addresses as an instruction immediate constant. > To perform I/O to a arbitrary port address (one not known at > compile/assembly time) you would generate the I/O instruction > with a RET into writable memory and call it. To avoid interrupt > reentrancy issues, this should done on the top of stack. > > Later the Z80 and 8086 added I/O instructions that allowed > port addresses to be in a register. > > Data General Nova Input and Output instructions were similar, > and IIRC also IBM 360 START CHANNEL, in only allowing immediate > constant port address. While neither was interested in ROMability, > performing arbitrary port I/O required generating and executing > self modifying code which interacts with prefetch buffers. > They later added register variants of I/O instructions. > > Eric > > > Thanks, Eric. I'm adding it to the wiki.
|
Next
|
Last
Pages: 1 2 3 4 Prev: TLBs which cache invalid (not present) entries Next: THANKS GOD! I GOT $2000 FROM PAYPAL.... |