SuperForth 64
in [Commodore]
|
From: BruceMcF on 3 Mar 2010 11:08 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 3 Mar 2010 17:13 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 3 Mar 2010 17:27 I guess I should plug Jim Lawless' blog for bringing this to my attention: http://jimlawless.wordpress.com/
From: christianlott1 on 6 Mar 2010 14:53 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 6 Mar 2010 17:17 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.
First
|
Prev
|
Pages: 1 2 3 Prev: Game where you had to defeat crocodiles Next: Feb. 20 Netherlands C= Show photos |