[MachineForth] Code Size, consulting vs chips

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

Roger Ivie wrote:
> BTW, is there a good reason Chuck didn't just use R for A in the X18?

Yes.  A and R should be used in exactly the way they have been
on F21.  B is to help with the fact that a level of indirection
is needed to get to the outside of the chip because of an
entirely different architecture on what Chuck always called
the "memory interface processor."

The P21 memory processor produces memory chip signals of
one specific type, no flexibility, not even changing the
timing except a little by a little voltage variation of
the board.  F21 has the same thing but a bunch of bits
in a control register to tweak this hardware interface.
You can 256K or 1M type DRAM chips, and there are six
bits for varying the speeds of the three hardware
memory busses (DRAM, 8-bit boot, SRAM).

c18 had NO memory interface. it is just a core, different
factoring.  In 25x it is hardware/software and mostly
software.  It appears to provide far more flexibility
that way to memory, but if you don't want the extra
level of indirection to slow everything down by
a factor of 4 or something you want that part done
in hardware.  But you want A and R for what they
always were.  No going back to P21 with ONLY A but
not memory access from R.  You WANT another memory
addressing register that matches the new hardware/
software memory interface designs.

> Seems to me there might be a bunch of reasons to do it that way:
> 
> 1) X18 lacks >R; using R for A would make A! into >R, recovering that
>    functionality.

No, it has >R and R>.  Chuck doesn't like those names.  Does he
call them PUSH and POP these days?  There are about a half
dozen different sets of opcode names in use you know.  But
there as SO few of them that there should not be any
confusion about which one is which.

The names I use are more consistent than Chuck's, or
at least look that way to me.  I was trying to make
them clear.  In any event the set is:

>R  also called push and !R by Chuck
R>  also called pop and R
R@+ also called R@ 
R!+ also called R!

Chuck prefers short.  I prefer consistent with the
opcode names associated with A:

A!
A or A@
@A
!A
@A+
!A+  since + here means inc  I don't like !R when it incs.

We only have
B!
@B
!B added on c18.

> 2) Something like : LIT @+ ; would get rid of the need for a special
>    opcode to deal with literals if R were used as A. Not saying that's
>    necessarily a good idea (it may be the case that literals are used
>    frequently enough to warrant a special opcode; I haven't studied
>    the problem).

True.  But defined words using calls are bigger and slower than
the inlined 5-bit opcode version.  Well worth having it.  Not
having it would be a big hits in lots of compounding ways
and would not be worth saving an opcode.
 
> About the only reason I can think of it being a bad idea is that it
> makes calling subroutines which use a value preset in A difficult;
> you'd need something like an OVER for the return stack if that were
> important.

Yes.  Instead of getting the return address from R and
doing what you say before a long call macro I tend to
let the compiler do that and use a literal for that.

return_adr # >R A >R ;
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe MachineForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main Machine Forth site   -   http://www.