Re: [colorforth] Understanding the x18 instruction jump table

["Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>]

> I'm aware of the "32 words - one for every 5-bit
> opcode" part.  I guess that's why I found the
> repeated instructions a bit odd.  It's also
> different from what was reported in Chuck's
> paper on the subject.
>
> http://dec.bournemouth.ac.uk/forth/euro/ef01/moore01b.pdf
>
> : inst ( n ) 1 slot +! 1f and jump ret nul call
> jmp nul nul jz jns n @+ @b @a !r !+ !b !a
> +* 2* 2/ - + and or drop dup over pop a nul
> b! push a!

That looks like what the instruction set looked like in the
2001/2002 timeframe.  It had several unimplemented opcodes
and !r at the time.  The instruction set has evolved over
the years as we profiled ROM BIOS and application code and
saw opportunities to improve things with instruction set
changes.

> These correspond 1 to 1 to the instruction table
> listed in the c18 compiler paper.
>
> http://dec.bournemouth.ac.uk/forth/euro/ef01/moore01a.pdf
>
> It's interesting to note that in the version from
> the paper there are 4 nuls in the jump table.
> In the source there's only 3.  Also the jump
> table from the paper includes a "ret" instruction.
> The source version does not, even though "ret"
> is defined as an instruction.

also known as ";"

> Also "!r" is absent.

!r was the !r+ opcode from f21 and it was part of
Chuck's original opcode set for c18 but replaced
later. An undocumented f21 opcode also returned.

> So 3 nuls minus 2 "missing"
> instructions plus 3 "repeated" instructions
> equals 4 nuls in the jump table in the paper.
> My conclusion?  The repeated instructions might
> as well be nulls.  (Admittedly I could be wrong
> on that).

It has evolved in the last five years.

> As for the "missing" instructions, well it seems
> "@r" had already been dropped since its missing
> from the c18 compiler paper, so I suppose losing
> "!r" isn't a biggie.  While there's no "ret" in
> the jump table, there is a ";" word defined for
> the x18 compiler.
>
> : ; 4 [ ip ] +! ;

Yes, also known as "ret" or "return"

> I'm not sure at the moment how this is supposed
> to work.  Most of the other instructions
> actually compile something into a "slot" but
> this is saying increment the IP by 4.  How does
> that execute a return?

That is odd.

In the real colorforth code, in the target compiler
for t18 ";" either compiles an opcode or, if the
previous word was a call, it converts that call into
a jump.  This tail-recursion saves the time and
energy by replaceing a call and a return with a
jump. It also saves one location on the return
stack which may be very valuable considering the
small stack size.

The simulator for c18 should do the following for ;
move the contents of R into the contents of PC
pop the return stack and copy what is below R into R
fetch the value from memory using PC and increment PC
put that value into the instruction word
set slot to 0
fetch the opcode in slot 0 of that word and execute it
and either advance the slot to 1 or branch to another
word and set slot to 0

okad2 has a target compiler to produce ram/rom
images for the c18s, and a software level simulation
and a hardware level simulation.  We can extract
the memory images and run them in okad in softsim or
hardsim, run them in ANS Forth simulation
or run third party simulation or fpga simulation
or we package them for serial or spi transport and make
boot and transfer images for fpga or vlsi hardware.

I mostly wrote c18 code in the colorforth environment
for a couple of years and ran various simulations. We
now have a separate environemnt for application
development and we can move images between these
and other environments.

okad2, and colorforth is used mostly by the technology
development group for cad work. And we are working on
a new release of colorforth.



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com