Re: [colorforth] 6502: MachineForth or traditional Forth?

[Eric Laforest <ecl@xxxxxxxxxxx>]

On Sat, Mar 06, 2004 at 09:53:01AM -0800, Samuel A. Falvo II thus spake:
> On Saturday 06 March 2004 05:10 am, Eric Laforest wrote:
> 
> I won't argue this, but inlining 2* and 2/, regardless of its bit width, 
> doesn't necessarily make it a MachineForth.  QuartusForth, for example, 
> for the PalmOS platform, is hardly a MachineForth, yet it too inlines 
> primitives.

It's MachineForth since the primitives (words built in assembly) are
the same set (and more) than used in the F21. Or am I missing something?

I also consider it MachineForth because it doesn't begin with the usual
EXIT, DOCOLON, etc... words, but with low-level stack operations from
which the former (or some form of them) may be built.

> Also, this is just one more reason why you should develop for the 65816 
> -- native support for 16-bit integers makes things MUCH simpler.  :)

True, but I'd still have to implement double-cell numbers for address
manipulations at least. Double-numbers show up often enough to warrant
implementing at the lowest level. There are quad-numbers in there, but only
briefly for scaling double-numbers, and no general (+, -, shift, etc...)
support for them.

And besides, the machines I need don't use a 65816.
(believe me, I'd love more power, but not at the expense of having to
rebuild all the hardware.)

> > Not at all. Most of the time, the flags are ignored.
> 
> Every LD, DE, or IN instruction sets flags.  Every single one.  Since the 
> stack operations must involve a LD, DE, or IN operation (e.g., if you 
> use X as the stack pointer, then INX or DEX is quite often the last 
> thing to run on every primitive), then that blows away your flags.

Yes. But like I said, they only matter in 5 places. Everywhere else they
are either not used, or end up being set appropriately via a LDA which
was part of the algorithm anyway.

The only place I have to worry about them outright is when wrapping an
unsigned multiplication or division operation, where I push the flags
onto the Return stack temporarily.

The flags are used internally, but do not exist for the programmer using
the primitives. Nor is there a Carry bit from that perspective.
(another reason for necessary double-numbers)

> > The downside is that conditionnal branches are relative to +/-128
> > bytes, and so the JMP words wrap them around a 'jmp' opcode to make
> > conditional branching absolute.
> 
> Even my Forth cross-compiler for x86 uses +/- 128 byte jumps for 
> everything except calls.  I find absolutely, positively zero need for 
> anything longer.

Ah. But I want to be able to conditionally jump to a word, which could be
many kilobytes away in the dictionnary.

Why? Removes the need for IF THEN ELSE compilation. Moves it from
compile time to edit time. Also moves tail call elimination to edit time.

> Should we move this to the MachineForth mailing list to keep this more on 
> topic?

Absolutely. Cross-posted, so I'll see you over there. :)

-- 
Eric LaForest
http://pet.dhs.org/~ecl/

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com