separate stacks

On Aug 3, 10:36 pm, m...@iae.nl (Marcel Hendrix) wrote:
> I don't find a single appearance of 'dup xor' in my database of Forth
> programs. I assume you have found that this can happen as a result of
> intermediate optimizations. Care to tell us what/where that is?
>
> -marcel

"dup xor"
is not an uncommon phrase in machineForth
as a size-speed-clarity optimization or variation of
"drop 0"

On f21 it would be 4ns and 10 bits vs 20ns and 30 bits.
Size optimization is even more important on smaller processors.

It is a ten bit "drop 0" with 5-bit opcodes or eight bits with 4-bit
opcodes. On very low cost, low power processors it is clearly a
code size and speed optimization.

Whether "dup xor" is clearer than "drop 0" is another issue and
depends on point of view.

Best Wishes

On Aug 4, 10:56 am, foxchip <f...@ultratechnology.com> wrote:
> On Aug 3, 10:36 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
> > I don't find a single appearance of 'dup xor' in my database of Forth
> > programs. I assume you have found that this can happen as a result of
> > intermediate optimizations. Care to tell us what/where that is?
>
> > -marcel
>
> "dup xor"
> is not an uncommon phrase in machineForth
> as a size-speed-clarity optimization or variation of
> "drop 0"
>
> On f21 it would be 4ns and 10 bits vs 20ns and 30 bits.
> Size optimization is even more important on smaller processors.
>
> It is a ten bit "drop 0" with 5-bit opcodes or eight bits with 4-bit
> opcodes. On very low cost, low power processors it is clearly a
> code size and speed optimization.
>
> Whether "dup xor" is clearer than "drop 0" is another issue and
> depends on point of view.
>
> Best Wishes

One can also freely use this phrase for just

"0"

when you don't care about what was on that stack previously
and have a hardware stack that can't overflow/underflow.

For instance in the stack initialization code of a program,
code that runs at program start or restart, might want to
begin by putting a zero on the stack. In machineForth it
is perfectly ok to use the phrase

"dup xor"

to begin things with a zero on the stack.

Thus in machineForth it has been a pretty common phrase
for nearly twenty years for either

"drop 0"

or when the drop doesn't matter at all just for

"0"

Best Wishes

On 4 Aug, 19:15, foxchip <f...@ultratechnology.com> wrote:
> On Aug 4, 10:56 am, foxchip <f...@ultratechnology.com> wrote:
>
>
>
>
>
> > On Aug 3, 10:36 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
> > > I don't find a single appearance of 'dup xor' in my database of Forth
> > > programs. I assume you have found that this can happen as a result of
> > > intermediate optimizations. Care to tell us what/where that is?
>
> > > -marcel
>
> > "dup xor"
> > is not an uncommon phrase in machineForth
> > as a size-speed-clarity optimization or variation of
> > "drop 0"
>
> > On f21 it would be 4ns and 10 bits vs 20ns and 30 bits.
> > Size optimization is even more important on smaller processors.
>
> > It is a ten bit "drop 0" with 5-bit opcodes or eight bits with 4-bit
> > opcodes. *On very low cost, low power processors it is clearly a
> > code size and speed optimization.
>
> > Whether "dup xor" is clearer than "drop 0" is another issue and
> > depends on point of view.
>
> > Best Wishes
>
> One can also freely use this phrase for just
>
> "0"
>
> when you don't care about what was on that stack previously
> and have a hardware stack that can't overflow/underflow.
>
> For instance in the stack initialization code of a program,
> code that runs at program start or restart, might want to
> begin by putting a zero on the stack. *In machineForth it
> is perfectly ok to use the phrase
>
> "dup xor"
>
> to begin things with a zero on the stack.
>
> Thus in machineForth it has been a pretty common phrase
> for nearly twenty years for either
>
> "drop 0"
>
> or when the drop doesn't matter at all just for
>
> "0"
>
> Best Wishes- Hide quoted text -
>
> - Show quoted text -

I was wondering as 0 = SI SO SO DI BA SO in nibz ops, which is a bit
faster than any other 0 generator. Whether this speed improvement is
worth the extra few cells is another matter.

cheers
jacko

Thomas Pornin <pornin@bolet.org> wrote:
> According to jacko <jackokring@gmail.com>:
> > : 0 dup xor ; ( fast zero constant when high lit penalty)

> It is:

> : 0 dup dup xor ;

> except that this does not work when the stack is empty (or rather, it
> duplicates a value from outer space, which may be harmless on some
> architectures, and devastating on others).

Forth Inc have always had a zero "guard cell" beneath the bottom of
the stack. It's a really good idea.

Andrew.

Andrew Haley wrote:
> Forth Inc have always had a zero "guard cell" beneath the bottom of
> the stack. It's a really good idea.

Why? I would think it would potentially mask problems and make testing
more difficult. If I try to pop off an empty stack, I want to be
explicitly told about it-- at least during development (minority
architectures that have circular stacks notwithstanding).

John Passaniti <nntp@japanisshinto.com> wrote:
> Andrew Haley wrote:
> > Forth Inc have always had a zero "guard cell" beneath the bottom
> > of the stack. It's a really good idea.

> Why? I would think it would potentially mask problems and make testing
> more difficult. If I try to pop off an empty stack, I want to be
> explicitly told about it-- at least during development (minority
> architectures that have circular stacks notwithstanding).

You _do_ get told. If you type . on an empty stack you get

.. 0 Stack empty

Instead of some random junk and (potentially) some fault.

Andrew.

On 6 Aug, 00:14, John Passaniti <n...@JapanIsShinto.com> wrote:
> Andrew Haley wrote:
> > Forth Inc have always had a zero "guard cell" beneath the bottom of
> > the stack. *It's a really good idea.
>
> Why? *I would think it would potentially mask problems and make testing
> more difficult. *If I try to pop off an empty stack, I want to be
> explicitly told about it-- at least during development (minority
> architectures that have circular stacks notwithstanding).

looking into the source of mid4th it does no stack bounds checking. I
think it is to do with optimizations on how often stc bounds have to
be checked. If a 0 is on stack then words which drop only on item need
no bounds checking internally, The execution loop can contain a check,
which causes a slow down. If there was no 0 all words which hange
stack depth would have to have checks.

On a debug platform I could see this as useful. My personal approach
will be a decompile or dump window which halts execution, and displays
either stack, current execution point, or any selected memory location
contained in any dump.

Fields would be hex value, word name of hex value, word at indirect
pointer of value, and string of pointed value. A TRAP word to switch
on such a debug view would work best.

I know people like rock solid stability, but it costs in code size and
speed, which is not the things you want to sacrifice in certain uses
of forth.

cheers.
jacko

jacko <jackokring@gmail.com> wrote:
> John Passaniti <n...@JapanIsShinto.com> wrote:
> > Andrew Haley wrote:
> > > Forth Inc have always had a zero "guard cell" beneath the bottom
> > > of the stack. *It's a really good idea.
> >
> > Why? *I would think it would potentially mask problems and make
> > testing more difficult. *If I try to pop off an empty stack, I want
> > to be explicitly told about it-- at least during development
> > (minority architectures that have circular stacks notwithstanding).
>
> On a debug platform I could see this as useful. My personal approach
> will be a decompile or dump window which halts execution, and displays
> either stack, current execution point, or any selected memory location
> contained in any dump.
>
> Fields would be hex value, word name of hex value, word at indirect
> pointer of value, and string of pointed value. A TRAP word to switch
> on such a debug view would work best.
>
> I know people like rock solid stability, but it costs in code size and
> speed, which is not the things you want to sacrifice in certain uses
> of forth.

Yes. It's pretty common for Forths to check stack depth before or after
the parser looks up a word and executes it. Or at the start or end of a
line of input. The cost is tiny at that point compared to the cost
you're already getting by interpreting. Then you don't find out where
the problem was internally, but you know the problem came wrt what you
typed.

It does make sense to have a special debug mode or a whole debug
compiler (that should be 100% compatible with the Forth system you'll
actually use). I first programmed in Forth on a system that couldn't
spare that luxury and I didn't miss it. I designed several debug
environments and then didn't use them. I gave them to my students and
they didn't use them either. I'm not sure why not.

Jonah Thomas wrote:
....
> It does make sense to have a special debug mode or a whole debug
> compiler (that should be 100% compatible with the Forth system you'll
> actually use). I first programmed in Forth on a system that couldn't
> spare that luxury and I didn't miss it. I designed several debug
> environments and then didn't use them. I gave them to my students and
> they didn't use them either. I'm not sure why not.

Back in the days when FORTH, Inc. taught classes with 15-20 students
sharing a single CPU, we developed a teaching system with extensive
internal checks to help prevent students' mistakes from crashing
everyone. It didn't help at all. I would look over a student's
shoulder and see a whole swat of error messages (Incomplete structure,
unbalanced stack, ...), and he/she would still try to execute the
offending word to see what would happen. I would say, "Wait a minute,
what about all those error messages?" and he/she would say, "Oh, yeah, I
don't know what's causing those, I just ignore them." The glares of a
roomful of inconvenienced students, however, was therapeutic.

People don't like nagging nannies. And asking them to assume
responsibility often works remarkably well.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Aug 5, 3:11*am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
>
> Forth Inc have always had a zero "guard cell" beneath the bottom of
> the stack. *It's a really good idea.
>
> Andrew.

All of the Forths I work with have the data stack above the return
stack (lower in memory if the stacks grow downward) so you have to
underflow the data stack quite a bit before you hit the top of the
return stack. Those are the kinds of machines where PAUSE changes
context by swapping out SP and RP. Some chips (but none that I work
with) have shallow hardware stacks whose content PAUSE may have to
swap out. But that's still pretty fast, as Forth Inc's PAUSE benchmark
for the PTSC1000 shows.

If you're writing a Forth for your own Forth chip, you can make LIT
smart enough to compile "dup dup xor" for 0 if it makes sense.

Since the OP is intent on designing a Forth chip, and since I've
designed a few of them (some of which were pretty awful), I could make
a few suggestions.

1. Take a look at some existing designs. There are many different ways
to build a stack machine. There's the Novix style (read Phil
Koopmans's book "Stack Computers"), there's MISC style (read
colorforth.com and see Bernd Paysan's b16), and there's stacks-in-
memory style geared toward FPGAs (see MicroCore).

2. If you decide to use block RAMs, FPGAs usually only support
synchronous read/write. Clock the block RAM at twice the CPU's clock
frequency to get somewhat asynchronous behavior and use two registers
for the top of stack. That's what MicroCore does. I've tried using a
single clock and doing early reads, but it's not worth the added
complexity.

3. Think about how you're going you're going to feed it instructions.
Will it be 16-bit instruction groups, 8-bit, etc? If you keep the
program memory on-chip, you can execute instructions as fast as you
can fetch them. There is no need to fetch a group of MISC-style
instructions and wait for the core to execute them one at a time. The
MISC approach can cause rumblings from the TPL group, so I prefer 8-
bit instructions and to keep the kernel in block RAM/ROM. Got big
code? a serial SPI flash device can supply 8-bit opcodes fast enough,
especially if your bottleneck routines are on-chip. Besides, some
devices have dual-rate and quad-rate modes that can supply up to 40M
bytes/sec.

-Brad