From: | "Alaric B. Williams" <alaric@abwillms.demon.co.uk> |
Newsgroups: | comp.compilers,comp.arch |
Date: | 29 Apr 1996 23:24:58 -0400 |
Organization: | Compilers Central |
References: | 96-04-059 96-04-083 96-04-094 96-04-103 |
Keywords: | architecture |
krste@ICSI.Berkeley.EDU (Krste Asanovic) wrote:
>Of course, it's difficult to make a case for say 32KB of L1 flash ROM
>alongside the L1 instruction cache in a general purpose system. Are
>any routines so important they're worth embedding at the L1 level?
Task switches and kernel calls come to mind - not just the
register/memory setup that needs to be swapped, but the operating
system's notion of what task is running and what it can do needs to be
changed. If the operating system, upon bootup, could adjust the
processor instruction set in these areas to account for its way of
working, why, that'd be excellent! What's more, if compiled FORTH were
to be executed, the CPU could be configured for optimised stack
operations, whereas with a higher level language with OOP, a
dereference-method-table-and-call would be nice, sort of:
CALL [[reg]+const]
I.e., get the pointer at the memory address in a register (or
immediate constant), and call the address pointed to by a specific
pointer in the table the first pointer points to (try saying that
fast!)
Most 'situations', be they languages or operating systems, that impose
a paradigm have these special situations that would benefit immensely
from one or two special opcodes, installed once and for all. When
microcode alteration becomes practical to the level where it is
customised by the compiled for the code being produced, even more good
stuff can result!
ABW
--
Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.hardcafe.co.uk/Alaric/">http://www.hardcafe.co.uk/Alaric/</A>
[I've used systems with completely customizable microcode. They ran as though
stapled to a snail. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.