 |
| View previous topic :: View next topic |
| Author |
Message |
kc5tja
Joined: 04 Jan 2003
Posts: 1338
Location: San Diego, CA
|
 Posted: Mon Jan 11, 2010 4:25 pm Post subject: |
 |
|
You have the wrong link, as they've somewhat reorganized the website. I recommend just visiting the home page of the project:
http://thinking-forth.sourceforge.net/
and going from there.
Concerning Starting Forth, an updated version is available online from: http://www.forth.com/starting-forth/index.html
The forth.com book has nearly all of the original illustrations restored, and is properly updated for ANSI Forth. |
|
| Back to top |
|
 |
BillO
Joined: 12 Dec 2008
Posts: 20
|
| Posted: Mon Jan 11, 2010 11:10 pm Post subject: |
|
|
Wow!
It seems when it comes to Forth, there is considerable scope for getting beyond one’s depth. Unfortunately I may not have the time to plumb these depths for a year or two, and at my advanced age that could mean a lifetime.
No problem though. The day I stop learning... well, I’d hate to think about it…
_________________
Bill |
|
| Back to top |
|
|
ElEctric_EyE
Joined: 02 Mar 2009
Posts: 365
Location: USA
|
| Posted: Tue Jan 12, 2010 12:00 pm Post subject: |
|
|
| GARTHWILSON wrote: | | I really should do a YouTube video of my interactive embedded development. We have a digital camera that can do video, but I guess we'll have to find and learn some video-editing software... |
You don't really need to edit alot, plus youtube allows you to annotate the video with text and do basic start and end clipping. If you make a large video and need to split it into parts, I think 2GB or ten minutes was the criteria, there's free windows software out there, not sure about linux. You will need alot of patience while uploading however! |
|
| Back to top |
|
|
BigEd
Joined: 11 Dec 2008
Posts: 397
Location: England
|
| Posted: Tue Jan 12, 2010 7:16 pm Post subject: searching for linux tools |
|
|
| (off-topic!) For any question about choosing or finding tools to run on linux, it's always handy to try a site:lwn.net search. In the case of video editing, Linux Weekly News has this three part series |
|
| Back to top |
|
|
BigEd
Joined: 11 Dec 2008
Posts: 397
Location: England
|
| Posted: Thu Jan 14, 2010 6:35 am Post subject: Advantages of 65816 for Forth |
|
|
Hi Garth
| Quote: |
The '02 ITC Forth averages about 12,500 primitives per second per MHz. My '816 does about 31,000 per second per MHz. |
Could you say which aspects of the 65816 give you that advantage? Does much of the improvement come from improved techniques which you could in theory apply in 6502? |
|
| Back to top |
|
|
GARTHWILSON
Joined: 30 Aug 2002
Posts: 1544
Location: Southern California
|
| Posted: Thu Jan 14, 2010 10:08 am Post subject: |
|
|
| Quote: | | Could you say which aspects of the 65816 give you that advantage? |
It's primarily that the '816 is so much more efficient at handling the 16-bit cells than the '02 which has to take 8 bits at a time and increment addresses or indexes in between and such. Here's the simple example of @ (pronounced "fetch"), which takes a 16-bit address placed on the top of the data stack and replaces it with the 16-bit contents of that address:
| Code: | For 6502:
LDA (0,X)
PHA
INC 0,X
BNE fet1
INC 1,X
fet1: LDA (0,X)
JMP PUT
; and elsewhere, PUT which is used in so many places is:
PUT: STA 1,X
PLA
STA 0,X
For the '816, the whole thing is only:
LDA (0,X)
STA 0,X ; For the '816, PUT is only one 2-byte instruction anyway, so there's no sense in jumping to it.
|
@ was given such a short name because it's one of the things used most. You can see the difference in the code length, 2 instructions versus 10.
Then there are the 816's extra instructions and addressing modes that improve efficiency, like MVN and MVP (the memory-move instructions), and the stack-relative addressing which helps in looping for incrementing the index and comparing to the limit and getting the indexes for nested loops. (Think of the typical I and J indexes in nested BASIC FOR-NEXT loops, except that you can do it in Forth without taking variable space.) These are just a couple off the top of my head.
Note of course that I'm not talking about running '02 Forth on an '816, something which in itself would not result in any performance gain. The '816 Forth was re-written to take advantage of the 816's extra capabilities.
Then because of the shorter assembly code, it became practical to re-write a lot of secondaries as primitives. In Forth, basically everything is a "word"-- even a variable which puts the address of its data space on the data stack. A primitive is a word that is defined in assembly language, so of course it has the best performance. A secondary is a word that is defined in terms of other Forth words, and those words can in turn be primitives or secondaries (or any mix thereof). A secondary has overhead between each pair of words. Even in subroutine-threaded Forth, that usually means a JSR/RTS pair. So to execute a single secondary, you might, depending on its complexity, execute a lot of JSRs and RTSs. In indirect-threaded Forth which is what I'm using and is slower but not without its advantages, there are almost no JSRs or RTSs, but there's often nest and unnest (which have functions similar to JSR and RTS), and there's always NEXT which is the inner loop, and these add overhead. The nice thing on the '816 is that the assembly language becomes short enough that now you can suddenly justify taking a lot of those words that pretty much had to be secondaries on the '02 and re-write them as primitives, not only speeding them up a lot but sometimes even making them shorter instead of longer!
BTW, to avoid too much confusion if you come across another teminology-- primitives are also called "code definitions," and secondaries are also called "colon definitions."
Last edited by GARTHWILSON on Mon Mar 15, 2010 4:25 am; edited 1 time in total |
|
| Back to top |
|
|
BigEd
Joined: 11 Dec 2008
Posts: 397
Location: England
|
| Posted: Thu Jan 14, 2010 7:48 pm Post subject: |
|
|
| Thanks - that's a great explanation. Interesting that the 16-bit registers running through an 8-bit wide memory interface doesn't hurt too much (which is to say, it might hurt to some extent, but you still got a very impressive speedup and density improvement.) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
