Re: Z80 Forth

Jason Kemp wrote:

> That's a book I've picked up recently and I have seriously considered 
> following its guidance on a z80 system (or emulator, but the idea of 
> using real hardware still seems more fun).

Yes, even a reimplementation on some FPGA board is more fun than an
emulator though it is really just another kind of emulation. This is
more of an emotional than logical issue.

> The lore says that if you 
> want to understand Forth you really need to write your own, or at least 
> it seems that everyone who's potty about Forth does write their own.

Trying to do your own helps make some very wierd design choices in
existing Forths start to make sense. But I don't think it is strictly
needed to go as deep as you want - it depends on your learning style.

> At 
> the moment though I'm resisting, assuming that it will save me some 
> learning time just to dissect CF (which is bound to be far better than 
> anything I could produce myself) instead, but perhaps it would be useful 
> to go z80 for a season.  The author suggests that it is feasible to have 
> something running from scratch in a few days.  Swings and roundabouts.  
> What would you advise me?

The book was written when the great debate was about direct vs indirect
threaded code. The only subroutine threaded version I was aware of was
Stoic and that wasn't even considered a Forth by many people. With
Machine and Color Forth the mix of subroutine threading and native
compilation has been the way to go. The focus has been on MISC but it
works well enough on the Pentium and shouldn't be any worse on a Z80.

I always think that a good historical perspective is extremely valuable
but everyone has their own priorities. Looking at older Forths (or
recreating them on your own) will give you a much larger context in
which to understand CF but will also take up a lot of your time.

One interesting thing is that most languages get more complicated as
time goes by. So looking at older versions and text will give you a good
subset of current implementations and help you see what the core stuff
was (what gets added later tends of be exotic details more than new
fundamentals) and will better prepare you to read recent texts. The two
exceptions I am aware of are Forth (at least Chuck's branch) and Self (a
version of Smalltalk). For those the later versions were simplified and
it might be better to ignore the history at first.

> The main trouble I'm finding with Pentium is this gigantic, complicated 
> instruction set, especially working backwards from op codes.  Here's one 
> if anyone could shed light on:
> : 2/ f8d1 2, ;
> Arithmetic shift right.
> The op code is D1 F8, which I think must be the assembly instruction SAR 
> EAX,1 but I end up with the opcode D1 38. The manual says the SAR op 
> code is D1 /7, so the reg/opcode  field (bits 3-5) is 7 the r/m field 
> (bits 0-2) specifies the register, so is 0 for EAX, but the Mod field 
> (bits 6&7) ...
> Ah, the Mod field needs to be 3 to address the register, rather than the 
> address held in the register.  So F8 is correct.
> 
> Anyway, it's taken me ages to get to this point, and you just don't have 
> these problems on a z80 (nor a 68000 from the even smaller experience I 
> had of that).  It's slow to work out, and I still marvel at the fact 
> that Charles Moore has actually written for this processor 
> 'sourcelessly'.

You can use as little of the Pentium as you want. Not many instructions
are actually used in CF and this subset is not that different from a
subset of the Z80. The complexity of the x86 is a serious problem for
anyone wanting to implement one or creating a compiler that must make
use of every little feature to keep up with the competition.

> I suppose there won't be these difficulties on that 
> SEAForth chip.

No, though fitting the instructions into the slots is a lot more
complicated than the 2, used above. But you create some words to hide
that and then don't worry about it.

-- Jecel