From: BruceMcF on
Oops, hit the wrong key

On Mar 3, 10:58 am, BruceMcF <agil...(a)netscape.net> wrote:

NEXT:
 CLC
 LDA IP
 ADC #2
 STA IP
 BCC START
 INC IP+1
START:
 LDY #1
 LDA (IP),Y
 BEQ EXIT
 BMI ENTER
 STA W+1
 DEY
 LDA (IP),Y
 STA W
 JMP (W)
ENTER:
AND #$7F
STA W+1
DEY
LDA (IP),Y
TAY
LDA IP+1
PHA
PDA IP
PHA
STY IP
LDA W+1
STA IP+1
JMP START
EXIT:
CLC
PLA
ADC #2
STA IP
PLA
ADC #0
STA IP+1
JMP START

As a first start, the data stack can be X-indexed on the stack page,
starting at the top of the area the C64 uses and building up. 128
bytes is plenty for data stack and 64 bytes is plenty for return
stack, so the stack page has ample space for a single-tasking Forth.

If upgrading to a pre-emptive multi-tasking Forth, you'd switch the
data stack to two pages elsewhere in RAM, high bytes in one, low bytes
in the other. That gives four independent 128 byte data stacks just by
switching X in the task switch. A page for USER variables and
independent PAD, and you have one background task available for a
scheduler, and two background tasks available for interupt-driven I/
O.
From: BruceMcF on
On Mar 3, 11:08 am, BruceMcF <agil...(a)netscape.net> wrote:

I just noticed that it can be made relocatable (though of course the
dictionary would not be without the "compile it again at a different
location and find the words that are offset" trick):

NEXT:
  CLC
  LDA IP
  ADC #2
  STA IP
  BCC START
  INC IP+1
START:
  LDY #1
  LDA (IP),Y
  BEQ EXIT
  BMI ENTER
  STA W+1
  DEY
  LDA (IP),Y
  STA W
  JMP (W)
ENTER:
 AND #$7F
 STA W+1
 DEY
 LDA (IP),Y
 TAY
 LDA IP+1
 PHA
 PDA IP
 PHA
 STY IP
 LDA W+1
 STA IP+1
BPL START
BRK
EXIT:
 CLC
 PLA
 ADC #2
 STA IP
 PLA
 ADC #0
 STA IP+1
BPL START
BRK

.... since if the top bit is not clear, in this implementation its
outside of the Forth dictionary and up in the memory for running
BASIC, I/O, the Kernal, the memory heap, the Block buffer, etc (RAM
under Kernal for graphics, RAM under BASIC rom for ALLOCATE, and
remember when launching into BASIC that nothing in ALLOCATED memory
can be passed..
From: christianlott1 on
I guess I should plug Jim Lawless' blog for bringing this to my
attention:

http://jimlawless.wordpress.com/
From: christianlott1 on
Bruce wrote: "Of course, fig-Forth is dead slow on the 6502 because
its indirect
threaded, and direct threaded is much faster, while subroutine
threaded is faster again. SO the fastest C64 Forth was the subroutine
threaded Blazin' Forth. "

Reminds me of this paper on implementing Scheme:

Three Implementation Models for Scheme by. R. Kent Dybvig
http://www.ai.cs.kobe-u.ac.jp/~kawamura/pukiwikiplus/index.php?plugin=attach&refer=scheme&openfile=ThreeImplementationModelsforScheme.pdf

"The first is a heap-based model used in some form in most Scheme
implementations to date; the second is a new stack-based model that is
considerably
more efficient than the heap-based model at executing most programs;
and
the third is a new string-based model intended for use in a multiple-
processor implementation of Scheme."
From: BruceMcF on
On Mar 6, 2:53 pm, christianlott1 <christianlo...(a)yahoo.com> wrote:
> the third is a new string-based model intended for use in a multiple-
> processor implementation of Scheme."

A string based model! But don't all the 11-dimensional arrays chew up
boatloads of RAM?

http://en.wikipedia.org/wiki/String_theory

IOW, I know what heap based and stack based mean (a language does not
have to be a variant of Forth to benefit from having data stack and
return address stack separated ... indeed, one approach to getting C
to run more rapidly is to have return addresses on the return stack,
and and heap data either contained or pointed to in a dedicated X-
indexed page in memory, with the ZP treated like a very large register
bank) ... but string based mode, no idear.