Re: [colorforth] Understanding the x18 instruction jump table

[John Drake <jmdrake_98@xxxxxxxxx>]

Hello Jeff.  Thanks for responding.  I know you
guys are really busy these days.  

--- Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx> wrote:

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

Yes.  I realize the paper is several years old 
(back when Chuck was working with Enumera?) and
a lot has happened since then.  But before I dove
into this, I thought the x18 compiler/simulator
that's available on the net was in sych with
Chuck's papers on the subject.  I see now that's
not the case.  

I'm wondering how much further
I can go with what's there.  I can step through
the existing sample x18 code as well as write
simple code myself (no branching, looping or
calls).  I'm not sure how much of this is me,
and how much is the code I'm using.  For
instance I can compile an x18 "if then"
but it doesn't give expected results.  On
the other hand I can't compile a "begin
until" loop because "begin" is not defined 
in the code I have.

I guess I can wait until VentureForth comes
out, though I was trying to get a jump on
c18-like programming.  Still, I have learned
more about ColorForth in the process, so it's
not a total loss. :)

> > 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 ";"

Yes.  I was just wondering why neither ";" nor 
"ret" were in the jump table.  But it's probably 
just an issue in this particular code.
 
> > : ; 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.

I saw this in Chuck's paper:

: ; call? @ dup 4000 or drop if dup 200 or drop
if 0 and i, ; then then 2/ ip @ +! ;

Sounds like what you're talking about.
 
> 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

The code I have just does this:

: ret -r pc ! ;

And since this isn't in the jump table or called
from any other word it's really dead code.

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

Is that separate environment "VentureForth"?

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

Great!  Looking forward to the new release.
Will it include an up to date c18 compiler?  
Any rough estimate on the release date?

Regards,

John M. Drake

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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