home .. forth .. misc mail list archive ..

Re: MISC-d Digest V99 #70


In message <3.0.3.32.19990712141153.006c7f3c@mail.sandpipers.com>, John
Rible <jrible@sandpipers.com> writes
>At 06:16 PM 07/12/99 +0100, Keith Wootten wrote:
>>
>>ShBoom II (PSC1000) can only branch to (32bit) cell boundaries, and not
>>to arbitrary byte opcodes.  The branch instruction includes the branch
>>as a literal, and can be 1 2 3 or 4 bytes long, depending on its
>>position in the instruction group.
>
>That's true for the pc-relative branches and calls ONLY.
>
>The call & branch opcodes which use the top-of-stack as the address, the
>return opcode, and the single-step opcode can all transfer to ANY byte
>within the cell. This is complicated further by having to keep track of how
>many '32-bit literal' opcodes there were (so the correct 'next address' is
>used) and whether there is a byte literal within the cell (which must not
>be executed).

[snip]

Yes, the call (execute), return (exit) and indirect branch (goto) are byte
aligned, whereas the other branches are cell aligned.  I'm not sure why
this should be, or if there *is* a reason.

>A while back I called all of this stuff 'brain-damaged' in the context of
>Chuck's original shBOOM design. It sure adds cycles! And the decode is
>horrendous, lengthing the cycle time! But it does make it possible to write
>pretty good compilers, allowing most people to focus on the application.

How does it add cycles, and why does it make good compilers more
realisable?   A genuine question, I'm no chip or compiler designer, and I
know nothing of Chuck's original design.

>Don't expect me to make any moral judgements here--I don't think that the
>chip's complexity is evil, nor do I think Chuck's wrong for wanting the
>SYSTEM to be as simple as it can be. 

I can (and do) buy these chips from the US for $25 each in small
quantities.  They work, and run Forth extremely well.  The documentation
is (at last) good.  This is probably the best Forth chip around until MISC
chips become a commercial reality, and in the meantime I have to sell
stuff.  PSC1000 may not be perfect, but it's just about all we have.
That's the moral of my judgement.  

>I strongly believe that telling
>non-Forth programmers that they're wrong (and bad) for not using Forth is
>not a viable way to increase the number of Forth programmers (at least in
>the existing US culture).

It's fun, though, and they *are* wrong, and bad. 

Cheers
-- 
Keith Wootten