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
