ROMmability
|
From: Bernd Paysan on 3 Aug 2010 12:15 On Dienstag, 3. August 2010 15:02, Piotr Wyderski wrote: > Joe Pfeiffer wrote: > >> Being able to reflash the ROM doesn't affect whether an embedded system >> should be rommable. > > Sure, but why would one want a rommable system? Ok, let's stay with the embedded system. Flash is a lot more dense than SRAM, and even denser than DRAM. It's the cheapest memory you get there, therefore you want to put as much as possible into this cheapest memory. Embedded systems are much more cost-sensitive ;-). > I mean a CPU-related system, the ability to etch an FSM > or a LUT is obviously desirable. Yes, but that doesn't mean it can't be in ROM or flash. Actually, ROMable and flashable can be significantly different. E.g. the Gforth EC (stripped down version of Gforth for embedded control) is flashable, which means that all the incremental compiler stuff in a Forth compiler work with a flash memory underneath. Flash is bulk erase (usually all bits 1), and you can write individual bits to zero, which usually means "write once" (exception: you can later clear a flag bit if necessary). You can't do that with ROM, and the ROMable version will put all incremental compile stuff into RAM. You also don't need to organize patch vectors or something like that to allow small fixes bugs in your ROMed system - you simply reflash. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: Joe Pfeiffer on 3 Aug 2010 13:36 "Piotr Wyderski" <piotr.wyderski(a)mothers.against.spam.gmail.com> writes: > Joe Pfeiffer wrote: > >> Being able to reflash the ROM doesn't affect whether an embedded system >> should be rommable. > > Sure, but why would one want a rommable system? > I mean a CPU-related system, the ability to etch an FSM > or a LUT is obviously desirable. Right now I'm playing with 8-bit embedded systems -- no OS. No secondary storage. Running from ROM is the only reasonable way to work down in that league. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
From: Piotr Wyderski on 3 Aug 2010 13:58 Joe Pfeiffer wrote: > Right now I'm playing with 8-bit embedded systems -- no OS. No > secondary storage. Running from ROM is the only reasonable way to work > down in that league. Here's the point: I misunderstood the meaning of "rommability", so the answer is obvious. I thought that the "rommability" word used by Andy was for "the ability to translate hardware circuits into something like ROM-based LUTs", i.e. the FPGA-style design. And I was wondering why would one use a ROM-based solution if he can build the respective circuit directly. Best regards Piotr Wyderski
From: robertwessel2 on 3 Aug 2010 18:12 On Aug 2, 4:47 pm, EricP <ThatWouldBeTell...(a)thevillage.com> 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. S/360 Start I/O (SIO), and the Start Subchannel (SSCH) that replaced it with the big revamp of the I/O subsystem in XA, both used registers to address the device. With SIO (and its variants), the base +displacement in the instruction specified the device, so you could actually hard code a device address (so long as it was less the 0xfff), but that immediate value was always added to the specified register (with the usual register zero exception). A problem was that a word in low memory (the Channel Address Word) was used to specify the start of the channel program and some options. With SSCH on XA and later, the model changed, and the I/O device is always specified with a value in GPR1, and the address in the instruction points to the Operation Request Block (which basically replaces and significantly extends the CAW), so there are fewer reentrancy issues. But there has never been a requirement to modify code to do mainstream I/O on S/360 and its descendents. One minor exception that I know of is the Direct Control facility that was an option on some S/370s (I don't believe that was ever supported on any XA or later machines), which basically added a parallel port to the machine. There was provision for an eight bit output (which could be used to address one of 256 ports) which came from an immediate field in the two instructions in question. But that was a minor facility at best.
From: Andy Glew "newsgroup at on 3 Aug 2010 20:52 On 8/3/2010 10:58 AM, Piotr Wyderski wrote: > Joe Pfeiffer wrote: > >> Right now I'm playing with 8-bit embedded systems -- no OS. No >> secondary storage. Running from ROM is the only reasonable way to work >> down in that league. > > Here's the point: I misunderstood the meaning of "rommability", so > the answer is obvious. I thought that the "rommability" word used > by Andy was for "the ability to translate hardware circuits into something > like ROM-based LUTs", i.e. the FPGA-style design. And I was wondering > why would one use a ROM-based solution if he can build the respective > circuit directly. > > Best regards > Piotr Wyderski Sorry. I'll try to revise the wiki page to make it clearer. "ROMmable" = my cute name for instruction set and other featurewsture that make it easier to put code - executable instructions, and maybe some datatructures - into ROM.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: TLBs which cache invalid (not present) entries Next: THANKS GOD! I GOT $2000 FROM PAYPAL.... |