[self-interest] Re: hardware implementation of PICs [long]

Jecel Assumpcao Jr jecel at lsi.usp.br
Mon Sep 6 17:53:02 UTC 1999

Douglas Atique wrote:
> Hello, Jecel!
> >From all you have written, I have only one question: how do you deal with
> changes when you embed the language so deep into the hardware? You guys were
> discussing eliminating some bytecodes, changing the syntax of the language,
> and so on. If you change something, must you reimplement hardware?

There are two, entirely separate levels at which you can change
things in Merlin 6. Since the CPU is implemented using a Field
Programmable Gate Array you can redesign it as much as you want.
If you miss your old CP/M computers, for example, you can change
it to be compatible with a Z80 ;-)

The cache is divide into three regions:

  1) data cache
  2) microcode cache
  3) interpreter/compiler

Region 3 is initialized from the Flash memory when the system is
booted and doesn't change after that.

When the CPU tries to fetch microcode from region 2 and it isn't
there, then it jumps to the interpreter/compiler which reads
bytecodes from the main memory and either executes them directly
or generates some microcode and places it in region 2 (so the
next time we look for it we will find it).

So you can keep the hardware design of the CPU fixed and still
change the "macro instruction" format as much as you want by
rewriting the code that is stored in region 3. In fact, the
CPU could run Java or Smalltalk instead without any changes
to the hardware design itself.

> Also I'm curious to know how you write the "system software", like the
> compiler. In assembly?

The compiler will be written in Self. And since it will be a
program that knows how to translate Self into microcode (in
the case of Merlin 6), it can be simply applied to itself
to generate the bits that will go into region 3 of the cache.
Of course, the trick is getting the compiled compiler to be
small enough to fit in 16K words...

-- Jecel

More information about the Self-interest mailing list