Prev: TLBs which cache invalid (not present) entries
Next: THANKS GOD! I GOT $2000 FROM PAYPAL....
From: Piotr Wyderski on 3 Aug 2010 07:36
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.

But for what purpose? Today even the built-in microcode "ROMs" are
updatable.

Best regards
Piotr Wyderski

From: Paul Gotch on 3 Aug 2010 07:54
Piotr Wyderski <piotr.wyderski(a)mothers.against.spam.gmail.com> wrote:
> But for what purpose? Today even the built-in microcode "ROMs" are
> updatable.

Limiting the amount of DRAM you need in the system, which has power
benefits. If you can execute in place from flash then you don't need to
copy the executable image into RAM before running.

For example one of the reasons that Symbian is Not Dead Yet(tm). Is that it
can easily execute most of the OS and built in applications from flash.
Linux does support XiP but as far as I'm aware it doesn't work with
flash yet.

For very deeply embedded systems and microcontrollers execute in place
is an absolute must.

-p
--
Paul Gotch
--------------------------------------------------------------------
From: Joe Pfeiffer on 3 Aug 2010 08:19
"Piotr Wyderski" <piotr.wyderski(a)mothers.against.spam.gmail.com> writes:

> 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.
>
> But for what purpose? Today even the built-in microcode "ROMs" are
> updatable.

Being able to reflash the ROM doesn't affect whether an embedded system
should be rommable.
--
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 09:02
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.

Best regards
Piotr Wyderski

From: kenney on 3 Aug 2010 10:14
In article <3dKdnfm-u52LgcvRnZ2dnUVZ_sydnZ2d(a)giganews.com>, "newsgroup
at comp-arch.net" (Andy Glew) wrote:

> 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.

As far as I know every computer that held the OS or part of the OS in
ROM used vector tables. That was certainly the case with Microsoft ROM
Basic, the Atari ST and I think the Amiga. It may have been slower but
it took less memory as in most cases only one or two entries were likely
to be patched.

Ken Young
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....