New Micros, Inc

View Full Version : Forth

coadtoad

08-14-00, 02:29 PM

I have finished developing my FORTH system (HC11) and want to ROM all the code so it will execute on power up. Are there tools available for this? Can someone point me to a document that describes the process?---------- Stan Burnette

rob

08-14-00, 05:45 PM

Check out the discussion in this forum:http://www.newmicros.com/cgi-bin/forum//discussion.cgi?forum=1&discussion=6

rob

08-14-00, 06:05 PM

Also check out:http://www.newmicros.com/cgi-bin/forum//discussion.cgi?forum=3&discussion=4

tomscott

09-14-00, 12:34 PM

Stan Burnette I have finished developing my FORTH system (HC11) and want to ROM all the code so it will execute on power up. Are there tools available for this? Can someone point me to a document that describes the process? ----------------------------- Tomscott No tools , you must initially write F' code special to ROM it . Obviously all things that change must be in RAM and loaded under the ROM to work properly . BTW Every F' i've seen is indirect threaded in spite of the CALL and JSR instructions in all those MCU's that woulod speed it up by 5. Direct threaded F' nix's IP , NEXT and simply uses the CALL/RTS to make the speed go up by 5 . Obviously the X index is used for data stack . It's just plain stupid ! Maybe Brodie gave them the idea that they must emulate the LSI-11 EXACTLY and they could not figure that NEXT is 12 instructions that do same as CALL !! F' has 2 levels i call high level run and low level or primative run . A speed up is possible at primative level when entering a WORD that has only primatives by pointing the SP at a list of addresses of those prim's and then calling the first prim' . As the first pri reaches the RTS , the RTS JMPs directly to next pri' W/O need for a CALL . The HC12 has powerful instructions that allow stack to be coded many ways ( not HC11 ) . PUSH/PULL in HC12 is slow comparatively .

rob

09-14-00, 03:56 PM

Matching the Forth virtual machine onto the general purpose logic execution unit of a processor can yield several different mappings. Using RTS to jump to the next thread call by treating a word's body as a subroutine return stack, does indeed allow for fast execution of a list of primitives, but with any mapping there are limits. Don't have interrupts active or you'll either get your word body overwritten if it is in RAM, or you'll never be able to restore your context after an RTI.

tomscott

09-15-00, 11:34 AM

Using RTS to jump to the next thread call by treating a word's body as a subroutine return stack, does indeed allow for fast execution of a list of primitives,but with any mapping there are limits. Don't have interrupts active or you'll either get your word body overwritten if it is in RAM, or you'll never be able to restore your context after an RTI. --------------------------------------------- Having interupts active is not unique to any language , all languages get clobbered if INT's active at wrong time . Or maybe you were just being insulting and telling me i don't know how to program the INTs at the rigt time . Or maybe your just trying to deny the serious flaw i found 20 years ago in the indirect threaded Forths . There is no excuse for using a coded inner int' when the MCU has a CALL . Even non S/W types quickly see this error . How about it ? Anyone out there want a 5 times faster F' ? The addition of the CALL adds about 20% to code size . I had the very fast Z80 direct threaded F' written by Tom Sargeant of Tucson and it benched 10 times faster that UnivRochesterNY Forth . Tom even did statistics on the alphabet and used the 8th bit of the first few chrs of name to make dict' searches faster . He also wrote a 68000 F' that was very fast. F' must evolve . It needs to rid itself of unintuitive forms . Unintuitive to NON programmers . Thats why we still have Basic .

rob

09-15-00, 07:22 PM

<HTML> <BODY> <PRE> No insults intended, this is a discussion forum for exchanging useful ideas. As for enabling interrupts only at the right time kind of goes against the philosophy of interrupts. Interrupts are usually for hardware that needs servicing immediately or quicker than one can poll. Now if you disable interrupts before you run each of your primitives and then enable it afterwards, you will lose response time of your interrupts. In the worst case you run a long primitive and block an interrupt for a long enough time that the hardware is not serviced in time. That said, if you don't use interrupts at all, then you are free to use the return stack to execute your list primitives. It is the designer's choice and the designer needs to understand the limitations. As for finding serious flaws in Forth, there is a wealth of good articles published in FORML and Rochester proceedings as well as Forth Dimensions examining all the different ways of implementing the underlying virtual Forth machine. Using the return stack as you mentioned is just one of them. Subroutine threading is another one. I've implemented quite a number of methods over the years and raw speed is only one of many sometimes conflicting requirements. If you go for the subroutine call model with inlined JSRs and no coded inner interpreter, then be prepared to have your code get bigger because now there is an extra assembler instruction tagged onto each pointer. This can be recovered by doing inline optimization (peephole optimizations, again, many articles cover this topic well) but then the Forth compiler is no longer just , (comma). We still have Basic because it is, well basic. And it is supported by a Big company. We still have Forth as well because it is more of an engineering language as opposed to a Computing Science language and it is quite useful for booting Sun workstations, Mac computers, FedEx devices as well as a lot of other embedded systems most people don't know about. F' itself is not an application program. I don't know the semantics for F' but I assume that it is a dictionary searching primitive. Speeding up the primary dictionary searching word can make your code compile faster, but not run faster. I had to address this issue many years ago. Once I got the dictionary search primitive as fast as I could, compile times were still too long. We were compiling upwards of a Megabyte of code with about 8000 words. Instead, I bypassed the linear dictionary search (on the average 4000 words were searched) in favor of a hashed dictionary search (on the average 2 words were searched) and that really made a difference. I developed the code while I was waiting for the long compiles to finish. Once the new hashed dictionary lookup was in place, code compiled in a snap. What I'm alluding to, is that you can get some speedups by playing with the underground piping, but when you really want to speed things up, try changing the algorithms. There are many other issues here other than raw execution speed and I've just tried to touch on just a few. Rob</PRE></BODY> </HTML>

tomscott

09-25-00, 06:22 PM

Rob said > No insults intended, this is a discussion forum for exchanging useful ideas. As for enabling interrupts only at the right time kind of goes against the philosophy of interrupts. ..... --------------------- I'll save you from any further pain . Rob wants to argue , not produce . Can't do , can't do ..... You are wrong , Harware operates at a much lower speed and it must not INT the MCU in the microsecond range . No primative takes 200 microseconds in direct threaded F' . I will poll anything that needs MCU time slices in the 200 microsecond range . Notice how i don't use 2000 words to get idea across ? I'm working on a project/hobby to make micros program thru a tiny keypad with top keys as soft keys . The lower 40 by 2 Optrex will display the functions on the soft keys . This stupidity of 10 megabyte apps to program a micro that has a run time prog' of 8 kb is gotta die !! It takes 1 hour to learn BASIC , weeks to learn C ..... Oh ! I'll be putting programmers out of work !! You'll see many HP48GX's running hardware in industry ! They were not programmed by pro' programmers !!!

tomscott

09-26-00, 06:17 PM

Imagine a primative jumps directly to next primative because the RTS pops the ADDR into the PC ( no CALL needed) . An internal or external INT will push context on stk (SP) and an RTI will POP exactly the same number of items off the STK. So where's the problem ?!!! All MCU's can interrupt S/W at any point w/o getting confused !!! So whats your point ?! BTW I don't advocate Forth over all others . It needs a lot of improvement . Compiled Basic can be the best tool if you are not into C . In writting comp'ld BASIC there is no reason why the code it generates can't be the fastest/most compact . Both the programmer writting an app and the programmer who wrote the BASIC can screw it up . C is not appropriate for writting 4 KB on a micro . It was the only lang' for DOS/WIN' cause it had all the hooks . INT21 looked very easy in C . I and many here want to get a hardware job done , not become S/W experts , so give it a rest !!!

administrator

09-26-00, 06:28 PM

Thank you for participating on our forum, however 1 post is certainly enough to express your opinion or thought. multiple posts of the same text do not serve the needs of the people who wish to participate in your discussion or wish to learn from your input. Thank you

rob

09-26-00, 06:36 PM

<HTML> <BODY> <PRE> > Imagine a primative jumps directly to next primative because the RTS pops > the ADDR into the PC ( no CALL needed) . An internal or external INT > will push context on stk (SP) and an RTI will POP exactly the same number > of items off the STK. So where's the problem ?!!! All MCU's can > interrupt S/W at any point w/o getting confused!!! So whats your point?! Your comment contains your answer. RTS pops an ADDR into PC because SP is pointing to the list of addresses of primitives. Now if SP is pointing to a list of addresses, then it can't be used as a stack because pushing items to the stack will overwrite the address of the primitives in the list. Fundamentally, if an interrupt happens when SP is not pointing to a writable area, the place to where it points to will be overwritten with the interrupt items. For this reason, when using the SP register other than for stack purposes, interrupts should be disabled. Rob </PRE></BODY></HTML>

tomscott

09-27-00, 02:55 PM

I'm trying to get a productive idea across and ROB insists that my s/w must use interupts for a few short primatives . INT's are disabled . Forth does not use the SP for data so those few primatives can work at the highest speeds and still have a STK . No , i'm not suggesting you string 100 primatives together using this method . F' rarely has 100 primatives contigous .

abilene

10-02-00, 10:52 PM

Rob, Are you still out there?

rob

10-03-00, 03:19 AM

Quite the opposite. All I'm saying is that when you use SP for an anything other than a stack pointer, you can not have interrupts enabled on the 68HC12. On a 68k processor, there is a separate system stack pointer register for interrupts so you would be able to operate a Forth system implemented as you describe with SP used as IP and still service interrupts. Rob

tomscott

10-03-00, 02:29 PM

For a short time that needs the fastest pos' code you copy a list off addresses to RAM and point the SP at them . It runs faster 'cause at end of SBR the PC is loaded with next SBR adress . If anything is stacked it only writes over the address that is no longer needed !! Confused ?BTW I have discovered a better Forth MCU . It has a wierd way of separating the program . The tightly coded , general purpose SBR's ( F' kernel) are in a tiny 8K Flash and the list of addresses ( indirect threaded F' ) is in 65 k of external RAM . The only truly executable code is in the 8K Flash . This is the F' kernel . It does not use the CALL as it takes too many clks , it uses the JMP(Z) and inc Z ( 2 clks ) . Call/RET takes 7 clks. last code in each primative is JMP(Z) , at start of each pri' is inc Z . This is the IP or NEXT . The 8K is equivalent to 32 k in the mixed prog/data mem model . The ATMEL 8515 is the only one in the AVR line that see's external 64 K RAM . Data sheet says 3 ma . Thats not a typo . 1/10 the current of HC11 and faster too . It burns the EEP and FLASH thru SPI or parallel . DIGIKEY has EVB for $49 (p207 STK200) , it does 8515 ,8535,1200,2313,2333,4313,4333 etc . You'll get a 8515-4pi ( it can run at 3 vdc, the 8pi can't ) .

rob

10-03-00, 03:19 PM

So the list to be executed is copied to RAM (might as well push to the current return stack as it would be the same thing and you wouldn't have to adjust SP before and after) each time it is to be executed in the worst case that interrupts are enabled all the time? Then you've really lost the increment in speed from using SP as IP. Rob