On Fri, 4 Dec 1998, Russell McMahon wrote:

> doing this is because the cpu + eerom cost is much lower than an
> alternative capability cpu. The new flash PICs will hopefully remove

That is very correct afaik. Microcode was invented by people facing the
problem of extended functionality in limited silicon and most present day
CISC computers use microcode for most complex operations (silicon monsters
like the Pentium [tm] don't count).

> I was thinking about what the minimum useful instruction set was that
> scold be executed by such a machine. Long ago there was an

Further rummaging in my tangled neuron collection: the approximate
instruction set of that Z80 based thing I did:

Five arithmetics: +, -, *, /, % Four logic: &, |, ^, !  Three branch:
GOTO, BRZ, BRC with relative address only, -1 relative address being
translated to program start (absolute 0), always.  No subroutines.
Implicitly addressed IO instructions for each of the IO registers (i.e.
IN0, IN1,... OUT0, OUT1,...).  Stack manipulations: DUP, DROP, (no OVER, I
had a 2-deep stack ;), and CONST. CONST was an implicit operator that
placed a constant onto the stack. It was a token that was followed by a
constant value in the instruction stream. Relative GOTOs were specified in
bytes, so the constants had to be calculated into jump vectors at compile
time (it was a 2-pass compilation using pen and paper ;). All tokens were
8 bits and all constants were 8 bits, and all ops were on 8 bits. I only
bring this up here, because it's all 8 bits wide (like a PIC and an E^2
for example). I think that I had a bit in each opcode to select whether
the flags were to be affected or not and I think that I had
increment/decrement instructions too.

Anyway the hardware was on the evil side, using 1xZ80A 1xLS04 (clock osc
and buffer), 1x2764, 1x8255, 1x7805, 4 caps a crystal and 4 resistors ;)
An optional EEPROM was connected to 3 pins of the 8255 (SPI), and
contained the program executed by the interpreter. I think that there was
a diode or two in there too, I don't remember all the details.

> I have a 15 page article on the language (BYTE (!), December 1978 pp
> 108-122.. An Easy Programming System - Joseph Weisbecker, NJ). He

Oops. In 1978 I was 9 years old and was going to start being REALLY
interested in electronics the next year or so ;)

> claims all sorts of advantages for this type of interpretive
> language. Says it typically takes 512 bytes for a full language and
> resultant code is 6 times as dense as BASIC (his claims). As I
> recall, CHIPOS could achieve some remarkable results considering its
> rudimentary nature. Something like this may be not too hard to write
> (he says a new language takes him about a week :-)).

Actually after you have been there a few times, it only takes a few hours.
Especially if you can re-use pseudo-code and do not fall in the pitfalls
that you have 'tried' out previously, in other projects.

Someone (William ?) has suggested a 'full' FORTH machine. This won't work
on a PIC. A FORTH machine assumes two things that a PIC has not got: A
dictionary of keywords (size!) and a sizeable stack (registers!). So, a
FORTH machine running on a PIC will have to have the FORTH call interface
'compiled' into direct absolute (?) compiled word addresses, and will have
to coax the programmer into using a shallow stack by FORTH standards.
Also, the interpreter needs to be flat-threaded or direct-threaded so as
to compensate for the very few return stack slots available on the PIC.
This means, that most FORTH words which are usually written in FORTH
itself and interpreted will have to be compiled to leave room for
application procedure calls.

Both the dynamic code extension problem (BUILDS/DOES FORTH paradigm) and
the limited operand stack size can be fixed by using a piece of EEPROM as
stack cache imho. I haven't done this, but I did most of the thinking, and
it should work (at horribly slow speed). Thus, the way to self-modifying
code for even the smallest PICs will be open ;) Let's see who comes up
with the 1st PIC virus. <g>

highly interested in the $SUBJ (minus viruses),

Peter